MTU в метрике EIGRP?

[burak-isiksoy]

Привет, Питер, На самом деле он используется, но не напрямую. MTU объявляется с обновлениями маршрутизации и хранится в базе данных топологии, и если ваш маршрутизатор имеет равные пути к одному и тому же пункту назначения и должен выбрать один из них, MTU вступает в игру с низким MTU игнорируется. BR Бурак

[Peter Paluch]

Здравствуйте, Бурак, Большое спасибо за ответ на мой вопрос! Я задал этот вопрос о MTU в EIGRP довольно давно (это было в 2006 году).
С тех пор я точно узнал то, что ты и предполагал — если метрики двух конкурирующих маршрутов одинаковы, EIGRP выберет путь с большим MTU.
Большое спасибо за завершение этой темы! EDIT (4 августа 2025 г.): Несмотря на всю информацию, циркулирующую в Интернете и, возможно, даже в различных учебных материалах и курсах по EIGRP, о том, что MTU используется тем или иным образом в алгоритме выбора оптимального пути, ничто из этого не соответствует действительности. Я сам был не прав. Мои знания о EIGRP до октября 2016 года были основаны на моих собственных экспериментах и изучении доступной публичной информации о EIGRP, но у меня не было доступа к внутренней базе знаний Cisco как авторитетному источнику информации. Будучи сотрудником Cisco с октября 2016 года, я теперь могу с уверенностью и авторитетностью сказать, что MTU не играет никакой роли в вычислении метрики EIGRP или выборе лучшего пути — абсолютно никакой. С уважением,
Питер

[Richard Burts]

Питер Вы задали очень хороший вопрос, и я считаю, что вы на правильном пути, пытаясь понять его. Ваше наблюдение верно: MTU является обязательным параметром при определении метрики EIGRP (для перераспределения) и является одним из параметров, которые объявляются. Вы также правы в том, что в расчетах EIGRP MTU не используется. Таким образом, правильный ответ заключается в том, что спецификация EIGRP включает MTU, но он не играет никакой активной роли в выборе пути, выполняемом EIGRP. HTH Рик HTH
Рик

[Peter Paluch]

Рик, Забавно, когда ответ может быть таким простым.
![] В любом случае, большое спасибо за ваш быстрый и подробный ответ. Мне было очень интересно его читать! С наилучшими пожеланиями, Питер

[Sam-CCNP]

Привет, У меня есть еще один вопрос по этому поводу. Включено ли MTU в обновление как наименьшее значение на пути к сети назначения (как BW)? То же самое касается нагрузки и надежности: включаются ли в обновление максимальные/минимальные значения по пути к сети назначения? Я знаю, что ни то, ни другое не используется в расчете метрики по умолчанию, поскольку их значения k установлены на ноль, но я просто хочу полностью понять, как все это работает. Спасибо. Сэм

[M02@rt37]

Здравствуйте
[, @Peter Paluch] MTU не используется в расчете составной метрики EIGRP, но включается в обновления EIGRP и используется для выбора маршрута только в качестве решающего фактора, когда несколько маршрутов имеют одинаковую метрику. А если MTU равны?
Маршрут с наименьшим IP будет установлен в таблице маршрутизации. [) С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[Peter Paluch]

Здравствуйте
[, M02@rt37]
, На самом деле информация об MTU неверна. MTU никак не влияет на выбор маршрута EIGRP. Мои знания о многих вещах, связанных с EIGRP (и другими проприетарными или внутренними механизмами Cisco) до примерно 2017 года, были основаны на моих экспериментах и исследованиях доступной информации, которая была обнародована в то время. Однако до октября 2016 года я не был сотрудником Cisco, и до этой даты у меня не было доступа к авторитетным источникам информации о внутренних особенностях. Несмотря на мое искреннее желание все правильно понять, я в некоторых вещах ошибся. Проблема MTU как возможного решающего фактора в алгоритме выбора пути EIGRP является одной из таких непреднамеренных ошибок. Некоторые из экспериментов, которые я проводил в то время, должны были быть ошибочными, и я интерпретировал их как использование MTU, если метрики были равны. Я был не прав. Теперь, имея доступ к внутренней документации и исходному коду, я могу с абсолютной уверенностью утверждать, что MTU не является и не было частью алгоритма выбора лучшего пути EIGRP ни в какой форме. Были соображения по его использованию, но они так и не были реализованы. Помните, что метрики EIGRP были взяты из IGRP, чтобы EIGRP мог стать полноценной заменой IGRP. MTU не использовался даже в IGRP, он просто рекламировался, как и количество прыжков — вы можете считать эти два параметра скорее вспомогательной информацией для устранения неполадок, передаваемой вместе с обновлениями, а не реальными компонентами метрики. Таким образом, вопрос о том, что произойдет, если MTU равна или не равна, не имеет значения — MTU не играет никакой роли в выборе пути. Что касается соседа с самым низким IP-адресом, который становится предпочтительным соседом, давайте проясним это. Это правило вступает в силу только в том случае, если у вас больше путей ECMP, чем вы можете установить в таблицу маршрутизации с помощью команды
maximum-paths
(по умолчанию установлено на 4). EIGRP будет внутренне сортировать преемников по их IP-адресам в порядке возрастания и передавать их в этом порядке в таблицу маршрутизации. Но если у вас есть пути ECMP, которые не превышают количество
maximum-paths
, все они попадут в таблицу маршрутизации, а не только один с самым низким IP-адресом следующего прыжка. Ссылка, которую вы привели здесь, где Дон Слайс (
@dslice
) объясняет изменения в исходном коде для случаев использования DMVPN, очень актуальна. Надеюсь, это немного прояснит ситуацию. С уважением,
Питер

[M02@rt37]

Здравствуйте
[, @Peter Paluch] Это многое проясняет! Спасибо! С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[Sam-CCNP]

Здравствуйте,
@Peter Paluch, Спасибо за объяснение MTU. Значения надежности и нагрузки взяты из интерфейса (интерфейсов), соединяющегося с соседями выше по потоку, которые рекламируют маршрут, или это самые низкие/высокие значения по пути? В отличие от MTU, они могут повлиять на расчет оптимального пути (при условии, что соответствующие значения не установлены на 0), поэтому я пытаюсь понять, как все это работает. Большое спасибо. Сэм

[Peter Paluch]

Здравствуйте,
@Sam-CCNP
, С надежностью и нагрузкой вы выполняете операции, аналогичные операциям с пропускной способностью: вы берете минимальный путь для надежности и максимальный путь для нагрузки: Вы сравниваете значение надежности в полученном маршруте с надежностью на принимающем интерфейсе и выбираете
меньшее
значение.
Вы сравниваете значение нагрузки в полученном маршруте с нагрузкой на принимающем интерфейсе и выбираете
более высокое
значение Однако, в отличие от пропускной способности и задержки, изменение надежности или нагрузки интерфейса не вызывает автоматического обновления в EIGRP. Значения надежности и нагрузки маршрута являются лишь моментальным снимком минимальной надежности и максимальной нагрузки пути в момент, когда маршрут был объявлен по какой-либо другой причине. Я полагаю, что когда появились расширения MANET для EIGRP, мы реализовали команды
dampening-change
и
dampening-interval
для EIGRP, чтобы позволить запускать обновления на основе общего процентного изменения метрики интерфейса. В этом случае даже изменение надежности и нагрузки должно запускать процесс обновления. При этом динамическая реакция на текущую надежность или нагрузку пути — дело довольно щепетильное. Это может легко привести к колебаниям маршрутов в сети, в результате чего высоконагруженный путь перестает быть лучшим, и трафик перемещается на какой-либо другой путь, только для того, чтобы обнаружить, что после снижения нагрузки исходный путь снова становится лучшим, и трафик возвращается на него... и так далее, и так далее. Это не является особенностью EIGRP — это фундаментальное следствие учета нагрузки пути в его общей метрике. Должен сказать, что я ни разу не видел, чтобы EIGRP в производственной среде настраивался с учетом надежности и/или нагрузки. А из-за неудобного поведения даже при использовании метрики по умолчанию, состоящей только из пропускной способности и задержки, если бы выбор был только за мной, я бы предложил всем просто «перейти» на использование только компонента задержки, то есть K3=1, а все остальные значения K установить равными 0. Это сделало бы вычисление пути EIGRP гораздо более понятным и интуитивным, а команду
задержки
каждого интерфейса можно было бы настроить произвольно, чтобы выбрать предпочтительные интерфейсы — так же, как мы делаем в IS-IS. Это не официальная рекомендация Cisco... но это определенно моя рекомендация С уважением,
Питер

[Joseph W. Doherty]

@Peter Paluch
, как обычно, один из ваших отличных и информативных ответов. Я думал дать примерно такой же ответ
@Sam-CCNP
вчера вечером, но был уставшим и решил сделать это сегодня утром (когда увидел ваш ответ). В любом случае, три момента, которые я хотел подчеркнуть, были следующими: 1) одно из соображений касается возможного влияния протокола маршрутизации, обрабатывающего постоянные обновления, особенно при изменении нагрузки на интерфейс. В основном это похожая проблема, как и при работе с нестабильным интерфейсом. (Как вы заметили, использование демпфирования может смягчить эту проблему, но достижение «правильного» результата сопряжено с собственными проблемами, т. е. необходимо реагировать, но не слишком активно). 2) проблема потоков, постоянно «переливающихся» между лучшими путями, которые меняются из-за их перенаправления на лучший путь. Вы тоже упоминаете об этом. 3) Решение этих проблем, особенно на аппаратном уровне, в эпоху создания IGMP/EIGMP, по моему мнению, было непрактичным. Кроме того, решение таких проблем было бы гораздо более требовательным к аппаратному обеспечению и потребовало бы гораздо большего объема процессорной логики, чем определено для EIGRP. Однако Cisco выпустила более позднюю технологию, которая, на мой взгляд, хорошо справлялась с «идеальным» использованием нескольких путей. Эта технология была первоначально выпущена как OER (оптимизированная пограничная маршрутизация), а ее версия V2 была переименована в
PfR
(маршрутизация по производительности) (IWAN и, как я подозреваю, SD-WAN имеют эту технологию). Я настроил и использовал OER/PfR, и моя реакция на эту технологию была «ВАУ». Смешно, но единственной неожиданной «проблемой» было то, что наша группа мониторинга сети больше не видела проблем WAN. Последнее было устранено путем исключения большей части трафика мониторинга сети из OER/PfR и/или мониторинга того, что делал OER/PfR. В любом случае, я упоминаю OER/PfR как возможную конструкцию EIGMP, в которой были предусмотрены потенциальные преимущества более интеллектуального выбора и использования путей. Изучение дополнительных k переменных EIGMP, возможно, в некоторой степени похоже на изучение маршрутизации по классам.

[Sam-CCNP]

Привет
[, @Peter Paluch]
, Спасибо за объяснение, оно имеет смысл и помогает мне лучше понять ситуацию. Это означает, что даже при значениях K, установленных по умолчанию, изменение нагрузки или надежности все равно может вызвать обновления? Или вызванные обновления ограничиваются случаями, когда метрика действительно изменяется, что в настройках по умолчанию происходит только при изменении задержки или BWmin? Да, я понимаю, что вы имеете в виду, говоря о значениях k. Я изучаю это для получения сертификата CCIE и иногда устанавливаю k = 3, а остальные значения — 0, чтобы упростить эксперименты, связанные с инженерией трафика, во время лабораторных работ. Большое спасибо. Сэм