По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Семантическое управление версиями (или семвер) – это формальное соглашение для определения номера версии новых выпусков программного обеспечения. Стандарт помогает пользователям программного обеспечения понять серьезность изменений в каждом новом дистрибутиве.
Проект, использующий семантическое управление версиями, объявляет основной номер версии (major), дополнительный номер версии (minor) и номер исправления (patch) для каждого выпуска. Строка версии 1.2.3 указывает на основную версию под номером 1, дополнительную версию под номером 2 и исправление под номером 3.
Номера версий такого формата широко используются как программными пакетами, так и исполняемыми файлами конечных пользователей, такими как приложения и игры. Однако не каждый проект точно следует стандарту, установленному semver.org.
Спецификация была создана для решения проблем, вызванных несовместимостью методов управления версиями между программными пакетами, используемыми в качестве зависимостей. Под «пакетом» и «зависимостью» мы подразумеваем библиотеку кода, предназначенную для использования в другом программном проекте и распространяемую диспетчером пакетов, таким как npm, composer или nuget. Это именно то применение семантического управления версиями, которое мы рассматриваем в этой статье.
Major, Minor и Patch
Важно понимать значение трех задействованных компонентов. Вместе они намечают путь разработки проекта и соотносят влияние каждого нового выпуска на конечных пользователей.
Major number (основной номер версии) – основной номер указывает на текущую версию общедоступного интерфейса пакета. Он увеличивается каждый раз, когда вы вносите изменения, которые требуют от существующих пользователей вашего пакета обновления их собственной работы.
Minor number (дополнительный номер версии) – дополнительный номер указывает на текущую функциональную версию вашего программного обеспечения. Он увеличивается всякий раз, когда вы добавляете новую функцию, но не меняете интерфейс вашего пакета. Он сообщает пользователям о том, что были внесены значительные изменения, но пакет полностью совместимым с предыдущими версиями с предыдущим дополнительным номером.
Patch number (номер исправления) – номер исправления увеличивается каждый раз, когда вы вносите какое-то незначительное изменение, которое не влияет на общедоступный интерфейс или общую функциональность вашего пакета. Его чаще всего используют для исправления ошибок. Потребители всегда должны иметь возможность не задумываясь установить последнюю версию исправлений.
Семантическая структура версии выпуска лучше всего моделируется в виде дерева. Наверху у вас изменения общедоступного интерфейса, каждое из которых отображается на основном номере. Каждая основная версия имеет свой собственный набор дополнительных версий, в которые добавляются новые функции без нарушения совместимости с предыдущими версиями. И наконец, дополнительные версии могут время от времени отлаживаться путем исправления некоторых ошибок.
Откуда начинать?
Большинство проектов должны начинаться с версии 1.0.0. Вы публикуете свой первый общедоступный интерфейс и первоначальный неизмененный набор функций. И поскольку вам еще не приходилось вносить никаких исправления, то и версия исправления – 0.
Теперь давайте посмотрим, что же происходит, когда вы вносите изменения в свой пакет. После вашего первоначального выпуска вы получаете отчет об ошибке от пользователя. Когда вы выпустите исправление, то правильный номер версии уже будет 1.0.1. Если бы вы затем выпустили еще одну версию с исправлением ошибок, то вы бы увеличили номер исправления до 2, т.е. номер версии уже был бы 1.0.2.
Тем временем вы также работали над новой интересной функцией. Это совершенно необязательно, поэтому пользователям не нужно ничего делать для обновления. Вы выпускаете эту версию как 1.1.0. – создана новая функциональная среда, но ее еще ни разу не исправляли. К сожалению, скоро приходят отчеты об ошибках, и среди ваших пользователей начинает распространяться версия 1.1.1.
Несколько месяцев спустя вы решили провести реорганизацию кода всего проекта. Некоторые функции были удалены или теперь доступны через объединенный интерфейс. Если вы выпустите эту работу, то люди, использующие текущую версию вашего пакета, должны будут внести серьезные изменения в свой проект. Пришло время опубликовать 2.0.0. в вашем репозитории пакетов.
Поддержание старых веток
Увеличение какого-либо номера в вашей строке версий не создает точку невозврата. После публикации 1.1.1 вы могли обнаружить ошибку, присутствующую в 1.0.2. Используя ветки в вашей системе контроля версий, вы можете произвести исправления в обеих версиях. В итоге вы получите 1.1.2 и 1.0.3.
Точно также вы можете поддерживать ветку 1.х вашего проекта, несмотря на выпуск 2.0.0. Может показаться странным публиковать 1.1.2 после 2.0.1, но это вполне нормальная практика. Семантическое управление версиями не создает линейный постоянно увеличивающийся номер версии; наоборот, оно предназначено для использования в качестве части модели разработки ветвления, которое использует простоту установки исправлений, предлагаемую системами управления исходным кодом, такими как Git.
Опубликованные версии должны быть неизменяемыми. После того, как вы создали версию 2.4.3, вы не можете «обновить» его, просто добавив дополнительный код в ту же строку версии. Вы должны присваивать новый номер версии каждому выпуску, чтобы пользователи всегда могли получить доступ к каждой конкретной версии вашего пакета.
Обработка пакетов, находящихся в стадии разработки
Как правило, вы всегда обновляете основную версию своего пакета всякий раз, когда вносятся изменения, несовместимые с предыдущими версиями. Когда вы находитесь в стадии разработки, то ваша кодовая база может дорабатываться очень быстро, что приводит к публикации множества основных версий.
Вы можете этого избежать, рекламируя свой проект как 0.y.z. Значение 0 в качестве основной версии означает, что ваш пакет неустойчив. Обычные правила в отношении совместимости с предыдущими версиями тут не применяются, поэтому вы можете выпускать новые версии, увеличивая только дополнительный номер и номер исправления. Это значит, что вы можете использовать 1.0.0 для обозначения первой «завершенной» версии вашего программного обеспечения.
Вы также можете добавить дополнительные «идентификаторы» в конец строки версии, используя дефис в качестве разделителя: 1.0.0-alpha.1. Вы можете использовать такой вариант для того, чтобы четко обозначить альфа- и бета-версии. Точно также вы можете включить метаданные сборки, добавив символ +: 1.1.0-alpha.1+linux_x86.
Заключение
Согласованное использование семантического управления версиями помогает пользователям быть уверенными в вашем проекте. Они могут четко видеть, как развивается ваша кодовая база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.
Объявление строки семантической версии необходимо при публикации в диспетчере наиболее популярных пакетов. Тем не менее, в конечном счете, вам решать, какие номера вы устанавливаете для каждого нового выпуска. Соблюдение стандарта четко сообщает о ваших намерениях пользователям и сводит к минимуму риск непреднамеренного нарушения чужой работы.
Сегодня, в этой статье, вы узнаете, как формируются соседства 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#
В первой статье серии EIGRP мы познакомились с функциями EIGRP, рассмотрели пример базовой конфигурации и набор команд проверки. Сегодня, в этой статье, мы углубимся в понимание того, как EIGRP устанавливает соседство, изучает маршрут к сети, определяет оптимальный маршрут к этой сети, и пытается ввести этот маршрут в таблицу IP-маршрутизации маршрутизатора.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Следующие статьи из цикла:
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Операции EIGRP могут быть концептуально упрощены в три основных этапа:
Этап 1. Обнаружение соседей: посредством обмена приветственными сообщениями EIGRP-спикер маршрутизаторы обнаруживают друг друга, сравнивают параметры (например, номера автономной системы, K-значения и сетевые адреса) и определяют, должны ли они образовывать соседство.
Этап 2. Обмен топологиями: если соседние EIGRP маршрутизаторы решают сформировать соседство, они обмениваются своими полными таблицами топологии друг с другом. Однако после установления соседства между маршрутизаторами передаются только изменения существующей топологии. Этот подход делает EIGRP намного более эффективным, чем протокол маршрутизации, такой как RIP, который объявляет весь свой список известных сетей через определенные интервалы времени.
Этап 3. Выбор маршрутов: как только таблица топологии EIGRP маршрутизатора заполнена, процесс EIGRP проверяет все изученные сетевые маршруты и выбирает лучший маршрут к каждой сети. EIGRP считает, что сетевой маршрут с самой низкой метрикой является лучшим маршрутом к этой сети.
Очень важно, что в когда вы читаете вышеописанные этапы, подробно описывающее обнаружение соседей EIGRP, обмен топологией и выбор маршрута, должны понимать, что в EIGRP, в отличие от OSPF, нет понятия назначенного маршрутизатора (DR) или резервного назначенного маршрутизатора (BDR).
Обнаружение соседей и обмен топологиями
Чтобы лучше понять, как маршрутизатор EIGRP обнаруживает своих соседей и обменивается информацией о топологии с этими соседями, рассмотрим рисунок ниже.
Шесть шагов, изображенных на рисунке выше, выполняются следующим образом:
Шаг 1. Маршрутизатор OFF1 хочет видеть, есть ли какие-либо EIGRP-спикер маршрутизаторы вне его интерфейса Gig 0/1, с которым он мог бы, возможно, сформировать соседство. Таким образом, он осуществляет многоадресную рассылку приветственного сообщения EIGRP (EIGRP Hello) на хорошо известный EIGRP multicast-адрес 224.0.0.10 с просьбой к любым EIGRP-спикер маршрутизаторам, идентифицировать себя.
Шаг 2. После получения приветственного сообщения маршрутизатора OFF1 маршрутизатор OFF2 отправляет одноадресное сообщение обновления (unicast Update message)обратно на IP-адрес маршрутизатора OFF1 10.1.1.1. Это сообщение обновления содержит полную таблицу топологии EIGRP маршрутизатора OFF2.
Шаг 3. Маршрутизатор OFF1 получает обновление маршрутизатора OFF2 и отвечает одноадресным сообщением подтверждения (Acknowledgement (ACK), отправленным на IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 4. Затем процесс повторяется, и роли меняются местами. В частности, маршрутизатор OFF2 отправляет приветственное сообщение на адрес многоадресной рассылки EIGRP 224.0.0.10.
Шаг 5. Маршрутизатор OFF1 отвечает на приветственное сообщение маршрутизатора OFF2 одноадресным обновлением (unicast Update), содержащим полную таблицу топологии EIGRP маршрутизатора OFF1. Это unicast Update достигается IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 6. Маршрутизатор OFF2 получает информацию о маршрутизации маршрутизатора OFF1 и отвечает одноадресным сообщением ACK, отправленным на IP-адрес маршрутизатора OFF1 10.1.1.1.
На этом этапе было установлено соседство EIGRP между маршрутизаторами OFF1 и OFF2. Маршрутизаторы будут периодически обмениваться приветственными сообщениями, чтобы подтвердить, что сосед каждого маршрутизатора все еще присутствует. Однако это последний раз, когда маршрутизаторы обмениваются своей полной информацией о маршрутизации. Последующие изменения топологии объявляются через частичные обновления, а не полные обновления, используемые во время создания соседства. Кроме того, обратите внимание, что сообщения обновления во время установления соседа были отправлены как одноадресные сообщения. Однако будущие сообщения обновления отправляются как многоадресные сообщения, предназначенные для 224.0.0.10. Это гарантирует, что все EIGRP-спикер маршрутизаторы на сегменте получают сообщения об обновлении.
EIGRP имеет преимущество перед OSPF в том, как он отправляет свои сообщения об обновлении. В частности, сообщения об обновлении EIGRP отправляются с использованием надежного транспортного протокола ( Reliable Transport Protocol (RTP). Это означает, что, в отличие от OSPF, если сообщение обновления будет потеряно при передаче, он будет повторно отправлено.
Примечание: аббревиатура RTP также относится к Real-time Transport Protocol (RTP), который используется для передачи голосовых и видеопакетов.
Выбор маршрута
Маршруты, показанные в таблице топологии EIGRP, содержат метрическую информацию, указывающую, насколько "далеко" она находится от конкретной целевой сети. Но как именно рассчитывается эта метрика? Расчет метрики EIGRP немного сложнее, чем с RIP или OSPF. В частности, метрика EIGRP по умолчанию является целочисленным значением, основанным на пропускной способности и задержке. Также, вычисление метрики может включать и другие компоненты. Рассмотрим формулу вычисления метрики EIGRP:
Обратите внимание, что расчет метрики включает в себя набор K-значений, которые являются константами, принимающие нулевые значения или некоторые положительные целые числа. Расчет также учитывает пропускную способность, задержку, нагрузку и надежность (bandwidth, delay, load, reliability). Интересно, что большая часть литературы по EIGRP утверждает, что метрика также основана на Maximum Transmission Unit (MTU). Однако, как видно из формулы расчета метрики, MTU отсутствует. Так в чем же дело? Учитывает ли EIGRP MTU интерфейса или нет?
В самом начале разработки EIGRP, MTU был обозначен как Тай-брейкер, если два маршрута имели одинаковую метрику, но разные значения MTU. В такой ситуации был бы выбран маршрут с более высоким MTU. Таким образом, хотя сообщение об обновлении EIGRP действительно содержит информацию MTU, эта информация непосредственно не используется в расчетах метрик.
Далее, давайте рассмотрим каждый компонент расчета метрики EIGRP и tiebreaking MTU:
Bandwidth (Пропускная способность): значение пропускной способности, используемое в расчете метрики EIGRP, определяется путем деления 10 000 000 на пропускную способность (в Кбит / с) самого медленного канала вдоль пути к целевой сети.
Delay (Задержка): в отличие от полосы пропускания, которая представляет собой "самое слабое звено", значение задержки является кумулятивным. В частности, это сумма всех задержек, связанных со всеми интерфейсами, которые используются чтобы добраться до целевой сети. Выходные данные команды show interfaces показывают задержку интерфейса в микросекундах. Однако значение, используемое в расчете метрики EIGRP, выражается в десятках микросекунд. Это означает, что вы суммируете все задержки выходного интерфейса, как показано в выводе show interfaces для каждого выходного интерфейса, а затем делите на 10, чтобы получить единицу измерения в десятки микросекунд.
Reliability (Надежность): надежность-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает на надежность связи. Например, значение надежности 255 указывает на то, что связь надежна на 100 процентов (то есть 255/255 = 1 = 100 процентов).
Load (Нагрузка): как и надежность, нагрузка-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает, насколько занята линия. Например, значение нагрузки 1 указывает на то, что линия загружена минимально (то есть 1/255 = 0,004 1%)
MTU: хотя он не отображается в Формуле вычисления метрики EIGRP, значение MTU интерфейса (которое по умолчанию составляет 1500 байт) переносится в сообщение обновления EIGRP, которое будет использоваться в случае привязки (например, два маршрута к целевой сети имеют одну и ту же метрику, но разные значения MTU), где предпочтительно более высокое значение MTU.
Для улучшения запоминания используйте следующий алгоритм Big Dogs Really Like Me. Где B в слове Big ассоциируется с первой буквой в слове Bandwidth. Буква D в слове Dogs соответствует первой букве D в слове Delay, и так далее.
Однако по умолчанию EIGRP имеет большинство своих K-значений равными нулю, что значительно упрощает расчет метрики, учитывая только пропускную способность и задержку. В частности, значения K по умолчанию являются:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
Если мы подставим эти дефолтные значения K в расчет метрики EIGRP, то значение каждой дроби будет равно нулю, что сводит формулу к следующему:
Чтобы закрепить знания по вычислению метрики, давайте проведем расчет метрики и посмотрим, соответствует ли она нашей таблице топологии EIGRP. Рассмотрим топологию, показанную на рисунке ниже.
Предположим, что мы хотим вычислить метрику для сети 198.51.100.0/24 от роутера OFF1 для маршрута, который идет от OFF1 до OFF2, а затем выходит в целевую сеть. Из топологии мы можем определить, что нам нужно будет выйти с двух интерфейсов маршрутизатора, чтобы добраться от маршрутизатора OFF1 до сети 198.51.100.0 /24 через маршрутизатор OFF2. Эти два выходных интерфейса являются интерфейсами Gig0/1 на маршрутизаторе OFF1 и интерфейсом Gig0/3 на маршрутизаторе OFF2. Мы можем определить пропускную способность и задержку, связанные с каждым интерфейсом, изучив выходные данные команд show interfaces, приведенных в следующем примере.
Определение значений пропускной способности и задержки интерфейса на маршрутизаторах OFF1 и OFF2
Из приведенного выше примера мы видим, что оба выходных интерфейса имеют пропускную способность 1 000 000 Кбит/с (то есть 1 Гбит/с). Кроме того, мы видим, что каждый выходной интерфейс имеет задержку в 10 микросекунд. Значение пропускной способности, которое мы вводим в нашу формулу вычисления метрики EIGRP, - это пропускная способность самого медленного канала на пути к целевой сети, измеряемая в Кбит/с. В нашем случае оба выходных интерфейса имеют одинаковую скорость соединения, то есть мы говорим, что наша "самая медленная" связь составляет 1 000 000 Кбит/с.
Для примера ниже показаны общие значения по умолчанию для пропускной способности и задержки на различных типах интерфейсов маршрутизатора Cisco.
Общие значения по умолчанию для пропускной способности и задержки интерфейса:
Наше значение задержки может быть вычислено путем сложения задержек выходного интерфейса (измеренных в микросекундах) и деления на 10 (чтобы дать нам значение, измеренное в десятках микросекунд). Каждый из наших двух выходных интерфейсов имеет задержку в 10 микросекунд, что дает нам суммарную задержку в 20 микросекунд. Однако мы хотим, чтобы наша единица измерения была в десятках микросекунд. Поэтому мы делим 20 микросекунд на 10, что дает нам 2 десятка микросекунд. Теперь у нас есть два необходимых значения для нашей формулы: пропускная способность = 1 000 000 Кбит/с и задержка = 2 десятка микросекунд. Теперь давайте добавим эти значения в нашу формулу:
Вычисленное значение показателя EIGRP составляет 3072. Теперь давайте посмотрим, является ли это фактической метрикой, появляющейся в таблице топологии EIGRP маршрутизатора OFF1. Выходные данные команды show ip eigrp topology, выведенные на маршрутизаторе OFF1, показаны в следующем примере.
Проверка метрики EIGRP для сети 198.51.100.0/24 на маршрутизаторе OFF1
Как и предполагалось, метрика (также известная как допустимое расстояние) от маршрутизатора OFF1 до Сети 198.51.100.0 /24 через маршрутизатор OFF2 составляет 3072. Напомним, что в этом примере мы использовали значения K по умолчанию, что также является обычной практикой в реальном мире. Однако для целей проектирования мы можем манипулировать K-значениями. Например, если мы обеспокоены надежностью каналом связи или нагрузкой, которую мы могли бы испытать на линии, мы можем манипулировать нашими K-значениями таким образом, чтобы EIGRP начал бы рассматривать надежность и/или нагрузку в своем метрическом расчете. В следующей статье мы рассмотрим, как мы можем изменить эти K - значения в EIGRP по умолчанию.