По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Для устранения неполадок мы должны пройти путь от нижней части модели OSI к верхней. Для этого нам придется начать с протоколов, которые используются для коммутации. Будем думать о VLAN, транкинге, об агрегировании каналов и связующем дерева. Мы рассмотрим различные протоколы и различные сценарии, где "что-то работает" не так. Мы решим эти проблемы с помощью комбинации команд show и debug. Первая остановка ... проблемы с интерфейсом!
Следующие статьи этого цикла:
Траблшутинг STP (Spanning tree protocol)
Устранение неисправностей EtherChannel
Case #1
В этом примере мы имеем коммутатор в центре и два компьютера, которые подключены к нему. Каждый компьютер имеет свой IP-адрес, и они должны иметь возможность пинговать друг друга. Мы будем считать, что компьютеры настроены правильно и там нет никаких проблем.
Интерфейс FastEthernet 0/1 находится в состоянии down. Это может указывать на проблему уровня 1, такую как неисправный кабель, неправильный кабель (кроссовер вместо прямого) или, возможно, нерабочая сетевая карта. Обратите внимание, что этот интерфейс работает в полудуплексном режиме. Если повезет, вы можете получить дуплексное сообщение через CDP, которое сообщит вам, что существует дуплексное несоответствие. Если вам не повезло, возможно, из-за этого ваш интерфейс переходит в состояние down. Имейте в виду, что гигабитный интерфейс не поддерживает halfduplex.
SwitchA(config)#interface fa0/1
SwitchA(config-if)#duplex auto
Изменим настройки интерфейса на duplex auto, чтобы коммутатор мог само настроиться.
Может быть, нам повезет...но не в этот раз, пинг не работает.
Интерфейс fa0 / 3, подключенный к хосту B, также не работает. После проверки кабелей и разъемов мы можем проверить ошибки дуплекса и скорости. Дуплекс включен в режим auto, так что это не является проблемой. Скорость была установлена на 10 Мбит, однако в то время как этот интерфейс является каналом Fast Ethernet (100 Мбит).
SwitchA(config)#interface fa0/3
SwitchA(config-if)#speed auto
Давайте переключим скорость на авто и посмотрим, что произойдет.
Похоже, что несоответствие скорости привело к тому, что интерфейс перешел в состояние down. Изменение его на auto-speed возвращает интерфейс в состояние up.
Это то, что мы искали. Интерфейсы, с которыми мы работаем, оба показывают состояние up/up. По крайней мере, теперь мы знаем, что нет никаких ошибок в кабеле, скорости или дуплексе.
Теперь наш пинг проходит.
Первый урок усвоен: Проверьте свои интерфейсы и посмотрите, отображаются ли они как up/up.
Case #2
Та же топология, но здесь другая проблема.
Хост A не может пропинговать хост B. Мы начнем с проверки интерфейсов:
Состояние интерфейса FastEthernet0/3 выглядит нормально, но что-то не так с интерфейсом FastEthernet 0/1.
Давайте изучим его подробнее:
Так так, мы видим сообщение err-disabled. Это уже дает нам понять, что проблема, где здесь (по крайней мере, это означает, что мы на что-то наткнулись).
Используйте команду show interfaces status err-disabled, чтобы узнать, почему интерфейс перешел в режим error-disabled. Это сообщит нам, что причина-безопасность порта.
Мы можем посмотреть на конфигурацию безопасности порта, и мы видим, что только 1 MAC-адрес разрешен. Последний MAC-адрес, который виден на интерфейсе - 000с.2928.5c6c.
Выше мы видим, что интерфейс был настроен для обеспечения безопасности на другой MAC-адрес. Именно по этой причине порт перешел в режим err-disabled.
SwitchA(config)#interface fa0/1
SwitchA(config-if)#no switchport port-security
Давайте уберем port security, чтобы решить эту проблему.
SwitchA(config)#interface fa0/1
SwitchA(config-if)#shutdown
SwitchA(config-if)#no shutdown
Главное, что вы не должны забыть сделать - это после очистки настройки от port security ваш интерфейс все еще находится в режиме err-disabled. Вам нужно выполнить команды отключения и включения порта (shutdown и no shutdown), чтобы он снова заработал!
Консоль сообщает нам, что интерфейс теперь включен.
Как мы видим эхо-запрос проходит между компьютерами. Проблема решена!
Урок 2 усвоен: проверьте, находится ли интерфейс в состоянии err-disabled, и если да, то: а) проверьте, почему это произошло, и Б) решите проблему.
Case #3
Давайте продолжим с другой проблемой. Та же топология, но опять проблема.
Эти два компьютера не "видят" друг друга.
Интерфейсы выглядят хорошо, никаких ошибок здесь нет.
И так мы видим, что port security отключена на этом коммутаторе. На данный момент мы, по крайней мере, знаем, что нет никаких проблем с интерфейсом и port security не фильтрует никакие MAC-адреса.
В данный момент это хорошая идея, чтобы проверить информацию о VLAN. Вы можете использовать команду show vlan, чтобы быстро проверить, к какой VLAN принадлежат интерфейсы.
Как вы можете видеть, наши интерфейсы находятся не в одной и той же VLAN.
SwitchA(config)#interface fa0/3
SwitchA(config-if)#switchport access vlan 1
Мы переместим интерфейс fa0/3 обратно в VLAN 1.
Теперь оба компьютера находятся в одной VLAN. Проблема решена! Урок 3 усвоен: убедитесь, что интерфейсы находится в нужной VLAN.
Case #4
Пришло время для другой проблемы! Наши два компьютера не пингуюся между собой. Вы теперь знаете, как выглядит неудачный пинг, поэтому скрин не будет публиковаться снова.
Интерфейсы не показывают никаких ошибок.
Мы изучим настройку VLAN. Вы видите, что FastEthernet 0/1 находится в VLAN 10, но мы нигде не видим FastEthernet 0/3. Вот возможные причины:
Что-то не так с интерфейсом. Мы проверили и убедились, что это не так, потому что он показывает состояние up/up, поэтому он кажется активным.
Интерфейс не в режиме access port, а в режиме trunk.
Быстрый взгляд на информацию о коммутаторе показывает нам, что нам нужно знать. Мы убедились, что интерфейс fa0/3 находится в режиме trunk, а native VLAN - 1. Это означает, что всякий раз, когда хост B отправляет трафик и не использует маркировку 802.1 Q, наш трафик заканчивается в VLAN 1.
SwitchA(config)#interface fa0/3
SwitchA(config-if)#switchport mode access
SwitchA(config-if)#switchport access vlan 10
Мы включим fa0/3 в режим доступа и убедимся, что он находится в VLAN 10.
Оба интерфейса теперь активны в VLAN 10.
Возможно, лучше проверить информацию на коммутаторе.
Теперь я могу отправить пинг с хоста а на хост Б...проблема решена!
Урок 4 усвоен: убедитесь, что интерфейс находится в нужном режиме (доступ или магистральный режим).
Case #5
Те же два компьютера, тот же коммутатор. Однако этот сценарий немного интереснее. Компьютеры не могут пинговать друг друга, поэтому давайте пройдемся по нашему списку "возможных" ошибок:
Интерфейсы выглядят хорошо, up/up-это очень хорошо.
Оба интерфейса находятся в VLAN 10, так что это тоже хорошо.
Просто чтобы быть уверенным...там нет port security. Это очень интересная ситуация. Интерфейсы работают (в состоянии up/up), мы находимся в одной VLAN, и нет никакой защиты портов. Что еще может быть причиной "перекрытия" трафика?
Ага! Это может быть не то, о чем нам может прийти в голову, но мы же можем использовать VACLs (VLAN access-list), чтобы разрешить или запретить трафик в пределах VLAN. Если вы устраняете неполадки коммутаторов, то необходимо проверить эту настройку, если все остальное кажется вам нормальным. В этом случае есть VACL, подключенный к VLAN 10, давайте проверим его.
Есть два порядковых номера ... 10 и 20. Порядковый номер 10 соответствует access-list 1, и его задача состоит в том, чтобы отбросить трафик. Давайте посмотрим, что это за access-list 1:
Не смущайтесь из-за заявления о разрешении здесь. Использование оператора permit в access-list означает, что он будет "соответствовать" подсети 192.168.1.0/24. Наши два компьютера используют IP-адреса из этого диапазона. Если он соответствует этому access-list, то VLAN access-map отбросит трафик.
SwitchA(config)# vlan access-map BLOCKSTUFF 10
SwitchA(config-access-map)# action forward
Давайте изменим действие на "forward" и посмотрим, решит ли оно нашу проблему.
Ну вот, все работает.
Урок 5 усвоен: если все остальное кажется нормальным, убедитесь, что нет никакого VACL!
Case #6
Давайте продолжим урок 6 с другой топологией. Теперь вы знаете, что нам нужно сначала проверить интерфейсы, а затем VLAN. В этом примере у нас есть те же два компьютера, но теперь у нас есть два коммутатора. Пинг от Хост А к Хосту Б не работает, так с чего начнем поиск?
Сначала мы проверим интерфейс fa0/1 на коммутаторе 1. Интерфейс запущен и работает, это switchport, назначенный для VLAN 10. Пока все выглядит неплохо. Port security не включен, так что нам не нужно беспокоиться об этом.
Давайте проверим то же самое на коммутаторе 2. Интерфейс работает, и он был назначен на VLAN 10.
В данный момент мы видим, что интерфейсы, "смотрящие" к компьютерам выглядят хорошо. В этот момент Вы могли бы сделать две вещи:
Подключите другой компьютер к коммутатору 1 и назначьте его во VLAN 10. Посмотрите, можно ли общаться между компьютерами во VLAN 10, когда они подключены к одному коммутатору. Сделайте то же самое на коммутаторе 2.
Проверьте интерфейсы между коммутатором 1 и коммутатором 2.
Мы сконцентрируем свое внимание на интерфейсах между коммутатором 1 и коммутатором 2, потому что там много чего может пойти не так!
Интерфейсы не показывают никаких проблем, время проверить информацию о switchport.
Коммутатор A находится в магистральном режиме и использует инкапсуляцию ISL.
Коммутатор B также находится в магистральном режиме, но использует инкапсуляцию 802.1Q. Имейте в виду, что (в зависимости от модели коммутатора) административный режим по умолчанию может быть dynamic auto. Два интерфейса, которые оба работают в dynamic auto режиме, станут портом доступа (access). Лучше всего самостоятельно переключить интерфейс в магистральный режим. В нашем случае оба интерфейса магистральные, так что это хорошо, но у нас есть несоответствие протокола инкапсуляции.
SwitchA(config)#interface fa0/15
SwitchA(config-if)#switchport trunk encapsulation dot1q
Мы изменим тип инкапсуляции, чтобы оба коммутатора использовали протокол 802.1Q.
Проблема решена! И опять все работает.
Урок 6 усвоен: убедитесь, что при настройке магистралей используется один и тот же протокол инкапсуляции.
Case #7
Вот опять тот же сценарий. Сейчас рассмотрим еще кое-что, что важно проверить при решении проблем trunk. Предположим, мы проверили и убедились, что следующие элементы не вызывают никаких проблем:
Интерфейсы (скорость/дуплекс).
Безопасность портов.
Конфигурация Switchport (назначение VLAN, интерфейс, настроенный в режиме доступа).
К сожалению, эхо-запрос между компьютерами все еще не проходит. Давайте взглянем на интерфейсы fa0/15 на коммутаторах:
Проверим, что оба интерфейса находятся в магистральном режиме и что мы используем один и тот же протокол инкапсуляции (802.1 Q). Здесь нет никаких проблем. Что-нибудь еще, что может пойти не так с этой магистральной связью? Да!
Магистраль может быть работоспособной, но это не означает, что все VLAN разрешены по магистральному каналу связи. В приведенном выше примере вы видите, что разрешена только VLAN 20.
SwitchA(config)#interface fa0/15
SwitchA(config-if)#switchport trunk allowed vlan all
SwitchB(config)#interface fa0/15
SwitchB(config-if)#switchport trunk allowed vlan all
Давайте позволим всем VLAN пройти магистраль.
По магистральной линии может передаваться трафик VLAN 10 между двумя коммутаторами. В результате пинг идет между компьютерами....еще одна проблема решена!
Урок 7 усвоен: всегда проверяйте, разрешает ли магистраль все VLAN или нет.
Case #8
Вот вам новый сценарий. Два компьютера, имеют разные IP-адреса. Коммутатор - это многоуровневый коммутатор. Поскольку компьютеры находятся в разных подсетях, нам приходится беспокоиться о маршрутизации.
Мы видим, что два компьютера не могут связаться друг с другом. С чего мы должны начать устранение неполадок?
Это статья не о настройке windows, но нам нужно обратить внимание на наши хосты. Поскольку компьютеры должны "выйти из своей собственной подсети", мы должны проверить, что IP-адрес шлюза по умолчанию в порядке и доступен.
Хост А может достичь шлюза по умолчанию, поэтому мы, по крайней мере, знаем, что хост А работает нормально.
Вот IP-конфигурация хоста B. Давайте проверим доступность шлюза по умолчанию!
Здесь тоже все работает. Мы знаем, что компьютеры рабочие, потому что они знают, как выйти из своей собственной подсети, и шлюз по умолчанию доступен. Пора проверить коммутатор.
Как мы видим, что хост А находится в VLAN 10 и хост B находится в VLAN 20. Мы не проверяли, включены ли интерфейсы, потому что мы можем пинговать IP-адреса шлюза по умолчанию. Это говорит о том, что fa0/1 и fa0/3 работают, но мы не знаем, к какой VLAN они принадлежат.
Были сконфигурированы два интерфейса SVI. Это IP-адреса, которые компьютеры используют в качестве шлюза по умолчанию. Так почему же наш коммутатор не маршрутизирует трафик?
Наличие IP-адресов на интерфейсах не означает автоматическую маршрутизацию трафика. Для этого нам потребуется таблица маршрутизации. Этот коммутатор не имеет
SwitchA(config)#ip routing
Давайте включим маршрутизацию на этом коммутаторе.
Давайте сделаем так, чтобы это выглядело получше. Теперь коммутатор знает, куда перенаправлять IP-пакеты на этом коммутаторе.
Вот так...теперь два компьютера могут достучаться друг до друга! Проблема решена! Урок 8 усвоен: если вы используете многоуровневый коммутатор для маршрутизации interVLAN, убедитесь, что интерфейсы SVI настроены правильно и что маршрутизация включена.
Мы рассмотрели наиболее распространенные ошибки, которые могут произойти с нашими интерфейсами, VLAN, транками и проблемами маршрутизации при использовании многоуровневых коммутаторов.
В следующей статье мы рассмотрим связующее дерево. Spanning-tree-довольно надежный протокол, но есть ряд вещей, которые могут пойти не так, как, вы ожидаете. Кроме того, из-за неправильной настройки могут произойти некоторые странные вещи...давайте рассмотрим траблшутинг STP в следующей статье.
Перед начало убедитесь, что ознакомились с материалом про построение деревьев в сетях.
Правило кратчайшего пути, является скорее отрицательным, чем положительным экспериментом; его всегда можно использовать для поиска пути без петель среди набора доступных путей, но не для определения того, какие другие пути в наборе также могут оказаться свободными от петель. Рисунок 4 показывает это.
На рисунке 4 легко заметить, что кратчайший путь от A до пункта назначения проходит по пути [A, B, F]. Также легко заметить, что пути [A, C, F] и [A, D, E, F] являются альтернативными путями к одному и тому же месту назначения. Но свободны ли эти пути от петель? Ответ зависит от значения слова "без петель": обычно путь без петель - это такой путь, при котором трафик не будет проходить через какой-либо узел (не будет посещать какой-либо узел в топологии более одного раза). Хотя это определение в целом хорошее, его можно сузить в случае одного узла с несколькими следующими переходами, через которые он может отправлять трафик в достижимый пункт назначения. В частности, определение можно сузить до:
Путь является свободным от петель, если устройство следующего прыжка не пересылает трафик к определенному месту назначения обратно ко мне (отправляющему узлу).
В этом случае путь через C, с точки зрения A, можно назвать свободным от петель, если C не пересылает трафик к месту назначения через A. Другими словами, если A передает пакет C для пункта назначения, C не будет пересылать пакет обратно к A, а скорее пересылает пакет ближе к пункту назначения. Это определение несколько упрощает задачу поиска альтернативных путей без петель. Вместо того, чтобы рассматривать весь путь к месту назначения, A нужно только учитывать, будет ли какой-либо конкретный сосед пересылать трафик обратно самому A при пересылке трафика к месту назначения.
Рассмотрим, например, путь [A, C, F]. Если A отправляет пакет C для пункта назначения за пределами F, переправит ли C этот пакет обратно в A? Доступные пути для C:
[C, A, B, F], общей стоимостью 5
[C, A, D, E], общей стоимостью 6
[C, F], общей стоимостью 2
Учитывая, что C собирается выбрать кратчайший путь к месту назначения, он выберет [C, F] и, следовательно, не будет пересылать трафик обратно в A. Превращая это в вопрос: почему C не будет перенаправлять трафик обратно в A? Потому что у него есть путь, стоимость которого ниже, чем у любого пути через A до места назначения. Это можно обобщить и назвать downstream neighbor:
Любой сосед с путем, который короче локального пути к месту назначения, не будет возвращать трафик обратно ко мне (отправляющему узлу).
Или, скорее, учитывая, что локальная стоимость представлена как LC, а стоимость соседа представлена как NC, тогда:
Если NC LC, то тогда neighbor is downstream.
Теперь рассмотрим второй альтернативный путь, показанный на рисунке 4: [A, D, E, F]. Еще раз, если A отправляет трафик к пункту назначения к D, будет ли D зацикливать трафик обратно к A?
Имеющиеся у D пути:
[D, A, C, F], общей стоимостью 5
[D, A, B, F], общей стоимостью 4
[D, E, F], общей стоимостью 3
Предполагая, что D будет использовать кратчайший доступный путь, D будет пересылать любой такой трафик через E, а не обратно через A. Это можно обобщить и назвать альтернативой без петель (Loop-Free Alternate -LFA):
Любой сосед, у которого путь короче, чем локальный путь к месту назначения, плюс стоимость доступа соседа ко мне (локальный узел), не будет возвращать трафик обратно ко мне (локальному узлу).
Или, скорее, учитывая, что локальная стоимость обозначена как LC, стоимость соседа обозначена как NC, а стоимость обратно для локального узла (с точки зрения соседа) - BC:
Если NC + BC LC, то сосед - это LFA.
Есть две другие модели, которые часто используются для объяснения Loop-Free Alternate: модель водопада и пространство P/Q. Полезно посмотреть на эти модели чуть подробнее.
Модель водопада (Waterfall (or Continental Divide) Model).
Один из способов предотвратить образование петель в маршрутах, рассчитываемых плоскостью управления, - просто не объявлять маршруты соседям, которые пересылали бы трафик обратно мне (отправляющему узлу). Это называется разделенным горизонтом (split horizon). Это приводит к концепции трафика, проходящего через сеть, действующую как вода водопада или вдоль русла ручья, выбирая путь наименьшего сопротивления к месту назначения, как показано на рисунке 5.
На рисунке 5, если трафик входит в сеть в точке C (в источнике 2) и направляется за пределы E, он будет течь по правой стороне кольца. Однако, если трафик входит в сеть в точке A и предназначен для выхода за пределы E, он будет проходить по левой стороне кольца. Чтобы предотвратить зацикливание трафика, выходящего за пределы E, в этом кольце, одна простая вещь, которую может сделать плоскость управления, - это либо не позволить A объявлять пункт назначения в C, либо не позволить C объявлять пункт назначения в A. Предотвращение одного из этих двух маршрутизаторов от объявления к другому называется разделенным горизонтом (split horizon), потому что это останавливает маршрут от распространения через горизонт, или, скорее, за пределами точки, где любое конкретное устройство знает, что трафик, передаваемый по определенному каналу, будет зациклен.
Split horizon реализуется только за счет того, что устройству разрешается объявлять о доступности через интерфейсы, которые оно не использует для достижения указанного пункта назначения. В этом случае:
D использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
C использует D для достижения пункта назначения, поэтому он не будет объявлять о доступности D
B использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
A использует B для достижения пункта назначения, поэтому он не будет объявлять о доступности B
Следовательно, A блокирует B от знания альтернативного пути, который он имеет к месту назначения через C, а C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петель пересекает этот разделенный горизонт. точка в сети. На рис. 12-5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направляемый в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. C, в терминах LFA, является нижестоящим соседом A.
Следовательно, A блокирует B от знания об альтернативном пути, который он имеет к месту назначения через C, и C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петли будет пересекать эту точку split horizon в сети. На рисунке 5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направленный в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. В терминах LFA, С является нижестоящим соседом (downstream neighbor) A.
P/Q пространство
Еще одна модель, описывающая, как работают LFA, - это пространство P / Q.
Рисунок 6 иллюстрирует эту модель.
Проще всего начать с определения двух пространств.
Предполагая, что линия связи [E, D] должна быть защищена от сбоя:
Рассчитайте Shortest Path Tree из E (E использует стоимость путей к себе, а не стоимость от себя, при вычислении этого дерева, потому что трафик течет к D по этому пути).
Удалите линию связи [E,D] вместе с любыми узлами, доступными только при прохождении через эту линию.
Остальные узлы, которых может достичь E, - это пространство Q.
Рассчитайте Shortest Path Tree из D.
Удалите канал [E, D] вместе со всеми узлами, доступными только при прохождении по линии.
Остальные узлы, которых может достичь D, находятся в пространстве P.
Если D может найти маршрутизатор в пространстве Q, на который будет перенаправляться трафик в случае отказа канала [E, D]- это LFA.
Удаленные (remote) Loop-Free Alternates
Что делать, если нет LFA? Иногда можно найти удаленную альтернативу без петель (remote Loop-Free Alternate - rLFA), которая также может передавать трафик к месту назначения. RLFA не подключен напрямую к вычисляющему маршрутизатору, а скорее находится на расстоянии одного или нескольких переходов. Это означает, что трафик должен передаваться через маршрутизаторы между вычисляющим маршрутизатором и remote next hop. Обычно это достигается путем туннелирования трафика.
Эти модели могут объяснить rLFA, не обращая внимания на математику, необходимую для их расчета. Понимание того, где кольцо "разделится" на P и Q, или на две половины, разделенные split horizon, поможет вам быстро понять, где rLFA можно использовать для обхода сбоя, даже если LFA отсутствует. Возвращаясь к рисунку 6, например, если канал [E, D] выходит из строя, D должен просто ждать, пока сеть сойдется, чтобы начать пересылку трафика к месту назначения. Лучший путь от E был удален из дерева D из-за сбоя, и E не имеет LFA, на который он мог бы пересылать трафик.
Вернитесь к определению loop-free path, с которого начался этот раздел-это любой сосед, к которому устройство может перенаправлять трафик без возврата трафика. Нет никакой особой причины, по которой сосед, которому устройство отправляет пакеты в случае сбоя локальной линии связи, должен быть локально подключен. В разделе "виртуализация сети" описывается возможность создания туннеля или топологии наложения, которая может передавать трафик между любыми двумя узлами сети.
Учитывая возможность туннелирования трафика через C, поэтому C пересылает трафик не на основе фактического пункта назначения, а на основе заголовка туннеля, D может пересылать трафик непосредственно на A, минуя петлю. Когда канал [E, D] не работает, D может сделать следующее:
Вычислите ближайшую точку в сети, где трафик может быть туннелирован и не вернется к самому C.
Сформируйте туннель к этому маршрутизатору.
Инкапсулируйте трафик в заголовок туннеля.
Перенаправьте трафик.
Примечание. В реальных реализациях туннель rLFA будет рассчитываться заранее, а не рассчитываться во время сбоя. Эти туннели rLFA не обязательно должны быть видимы для обычного процесса пересылки. Эта информация предоставлена для ясности того, как работает этот процесс, а не сосредоточен на том, как он обычно осуществляется.
D будет перенаправлять трафик в пункт назначения туннеля, а не в исходный пункт назначения - это обходит запись локальной таблицы переадресации C для исходного пункта назначения, что возвращает трафик обратно в C. Расчет таких точек пересечения будет обсуждаться в чуть позже в статьях, посвященных первому алгоритму кратчайшего пути Дейкстры.
Перед тем как начать чтение этой статьи, советуем ознакомиться с материалом про расчет пути по алгоритму Bellman - ford.
Алгоритм диффузного обновления (Diffusing Update Algorithm -DUAL) - один из двух обсуждаемых здесь алгоритмов, изначально предназначенных для реализации в распределенной сети. Он уникален тем, что также удаляет информацию о достижимости и топологии, содержащуюся в конечном автомате алгоритма. Другие обсуждаемые здесь алгоритмы оставляют удаление информации на усмотрение реализации протокола, а не рассматривают этот аспект работы алгоритма внутри самого алгоритма.
К 1993 году Bellman-Ford и Dijkstra были реализованы как распределенные алгоритмы в нескольких протоколах маршрутизации. Опыт, полученный в результате этих ранних реализаций и развертываний, привел ко "второй волне" исследований и размышлений о проблеме маршрутизации в сетях с коммутацией пакетов, что привело к появлению вектора пути и DUAL.
Поскольку DUAL разработан как распределенный алгоритм, лучше всего описать его работу в сети. Для этой цели используются рисунки 8 и 9. Чтобы объяснить DUAL, в этом примере будет прослеживаться поток A, изучающего три пункта назначения, а затем обрабатываются изменения в состоянии доступности для этих же пунктов назначения. В первом примере будет рассмотрен случай, когда есть альтернативный путь, но нет downstream neighbor, второй рассмотрит случай, когда есть альтернативный путь и downstream neighbor.
На рисунке 8 изучение D с точки зрения A:
A узнает два пути к D:
Через H стоимостью 3.
Через C стоимостью 4.
A не узнает путь через B, потому что B использует A в качестве своего преемника:
A - лучший путь B для достижения D.
Поскольку B использует путь через A для достижения D (пункта назначения), он не будет анонсировать маршрут, который он знает о D (через C) к A.
B выполнит split horizon своего объявления D на A, чтобы предотвратить образование возможных петель пересылки.
A сравнивает доступные пути и выбирает кратчайший путь без петель:
Путь через H помечен как преемник.
Возможное расстояние устанавливается равным стоимости кратчайшего пути, равной 3.
A проверяет оставшиеся пути, чтобы определить, являются ли какие-либо из них downstream neighbors:
Стоимость C составляет 3.
A знает это, потому что C объявляет маршрут к D со своей локальной метрикой, равной 3.
A сохраняет локальную метрику C в своей таблице топологии.
Следовательно, A знает локальную стоимость в C и локальную стоимость в A.
3 (стоимость в C) = 3 (стоимость в A), поэтому этот маршрут может быть петлей, следовательно, C не удовлетворяет условию выполнимости. C не помечен как downstream neighbors.
Downstream neighbors в DUAL называются возможными преемниками. Предположим, что канал [A, H] не работает. DUAL не полагается на периодические обновления, поэтому A не может просто ждать другого обновления с достоверной информацией. Скорее A должен активно следовать альтернативному пути. Таким образом, это диффузный процесс обнаружения альтернативного пути. Если канал [A, H] не работает, учитывая только D:
A проверяет свою локальную таблицу на предмет возможных преемников (Downstream neighbors).
Возможных преемников нет, поэтому A должен найти альтернативный путь без петель к D (если он существует).
A отправляет запрос каждому соседу, чтобы определить, есть ли какой-либо альтернативный путь без петель к D.
В C:
Преемником C является E (не A, от которого он получил запрос).
Стоимость E ниже, чем стоимость A для D. Следовательно, путь C не является петлей.
C отвечает со своей текущей метрикой 3 на A.
В B:
А - нынешний преемник Б.
Посредством запроса B теперь обнаруживает, что его лучший путь к D потерпел неудачу, и он также должен найти альтернативный путь.
Обработка B здесь не расписывается, а предоставляется выполнить самостоятельно.
B отвечает A, что у него нет альтернативного пути (отвечает бесконечной метрикой).
A получает эти ответы:
Путь через C - единственный доступный, его стоимость 4.
A отмечает путь через C как его преемника.
Других путей к D нет. Следовательно, нет подходящего преемника (downstream neighbor).
На рисунке 9 пункт назначения (D) был перемещен с H на E. Это будет использоваться во втором примере.
В этом примере есть возможный преемник (downstream neighbor).
Изучение D с точки зрения A:
A узнает два пути к D:
Через H стоимостью 4.
Через C стоимостью 3.
A не узнает никакого пути через B:
У B есть два пути к D.
Через C и A стоимостью 4.
В этом случае B использует как A, так и C.
B выполнит split horizon свого объявления D на A, потому что A помечен как преемник.
A сравнивает доступные пути и выбирает кратчайший путь без петель:
Путь через C отмечен как преемник.
Возможное расстояние устанавливается равным стоимости кратчайшего пути, равной 3.
A проверяет оставшиеся пути, чтобы определить, являются ли какие-либо из них downstream neighbors:
Стоимость H составляет 2.
2 (стоимость в H) = 3 (стоимость в A), поэтому этот маршрут не может быть петлей. Следовательно, H удовлетворяет условию выполнимости.
H отмечен как возможный преемник (downstream neighbors).
Если канал [A, C] не работает, просто рассматривая A:
A проверит свою таблицу локальной топологии на предмет возможного преемника.
Возможный преемник существует через H.
A переключает свою локальную таблицу на H как лучший путь.
Распространяющееся обновление не запускалось, поэтому пути не были проверены или пересчитано.
Следовательно, допустимое расстояние изменить нельзя. Он остается на 3.
A отправляет обновление своим соседям, отмечая, что его стоимость достижения D изменилась с 3 до 4.
Как вы можете видеть, обработка, когда существует возможный преемник, намного быстрее и проще, чем без него. В сетях, где был развернут протокол маршрутизации с использованием DUAL (в частности, EIGRP), одной из основных целей проектирования будет ограничение объема любых запросов, генерируемых в случае отсутствия возможного преемника. Область запроса является основным определяющим фактором того, как быстро завершается двойной алгоритм и, следовательно, как быстро сходится сеть.
На рисунке 10 показан базовый законченный автомат DUAL.
Вещи, входящие в route gets worse (ухудшение маршрута), могут представлять собой:
Отказ подключенного канала или соседа
Получение обновления для маршрута с более высокой метрикой
Получение запроса от текущего преемника
Получение нового маршрута от соседа
Обнаружен новый сосед, а также маршруты, по которым он может добраться
Получение всех запросов, отправленных соседям, когда маршрут ухудшается