По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Среди обилия различных вариантов довольно трудно выбрать ту модель базы данных (БД), который идеально подойдет под ваши нужды. Если говорить о разновидностях СУБД, то чаще всего предпочтение отдается реляционным базам.
В данной статье мы поговорим об устройстве реляционных баз данных, обсудим принципы их работы, а также плюсы и минусы использования этих систем. Кроме того, продемонстрируем примеры, которые наглядно показывают, как реляционные БД систематизируют данные.
Что такое реляционная база данных
Реляционная база данных – это тип БД, который специализируется на связях (отношениях) между элементами данных. Он позволяет устанавливать взаимосвязи между различными наборами данных и использовать эти связи для управления и обращения к связанным данным.
Для создания и поддержки данных во многих реляционных БД используется SQL (Structured Query Language - структурированный язык запросов).
Реляционные и нереляционные базы данных
Реляционные БД делают упор на отношениях между данными. Следовательно, реляционные БД должны хранить данные в строго структурированном виде. Это ускоряет индексирование и время ответа на запросы, а также улучшает безопасность и постоянство данных.
Нереляционные базы данных, наоборот, не так сильно зависят от структуры данных, поэтому могут хранить большие объемы данных, не теряя гибкости и легко масштабируя хранение и производительность.
Как структурируются данные в реляционных системах управления данными?
В реляционных системах управления данными (РСУБД) используется модель, которая структурирует данные в таблицы строк (их еще называют записями или кортежами) и столбцов (или атрибутов/полей). Обычно в столбцах размещаются категории данных, а в строки добавляются отдельные экземпляры.
В качестве примера рассмотрим онлайн-магазин. В нашей базе данных находится таблица с информацией о клиентах. В столбцах указываются имена клиентов и адреса, а в строках – данные по каждому клиенту.
Такие таблицы можно связать или соотнести с помощью ключей. Каждая строка в таблице идентифицируется с помощью уникального ключа (его называют первичный ключ - primary key). Этот ключ можно добавить в другую таблицу, и там он превратится во внешний ключ (foreign key). Отношение первичный/внешний ключ лежит в основе того, как работают РСУБД.
Вернемся к нашему примеру. Допустим, у нас есть таблица с заказами товаров. В одном столбце этой таблицы находится информация о клиенте. Сюда мы можем импортировать первичный ключ, который ссылается на строку с информацией по отдельному клиенту.
Таким способом мы можем ссылаться на данные или дублировать данные из таблицы с информацией о клиентах. Кроме того, теперь эти две таблицы связаны.
Примеры реляционных баз данных
Сейчас, когда мы рассмотрели, как работают РСУБД, пора поговорить о популярных примерах их использования.
MySQL
MySQL разрабатывалась как РСУБД с открытым кодом, затем ее купила компания Sun Microsystems (теперь это Oracle Corporation). Она по-прежнему доступна со свободной лицензией, но с добавлением проприетарных опций.
В MySQL заложена встроенная поддержка репликации с ACID-совместимостью, кластеризация без разделения ресурсов между узлами и поддержка многих движков БД. Но на некоторых движках SQL может работать некорректно.
MySQL преуспел в быстром вводе данных и масштабируемости, сохранив при этом высокую доступность и производительность. Все это делает MySQL крайне полезным в веб-разработке и создании приложений.
PostgreSQL
PostgreSQL – это бесплатный менеджер управления реляционными БД, доступный по свободной лицензии. В нем можно найти некоторые функции MySQL с весомым добавлением MVCC (multi-version concurrency contro - управление параллельным доступом посредством многоверсионности), поэтому такая система совместима с ACID.
PostgreSQL сохраняет высокий уровень гибкости и производительности даже при обработке больших баз данных. Это подходящее решение для пользователей, которым важна высокая скорость записи/чтения и разноплановый анализ данных.
Среди известных пользователей PostgreSQL стоит упомянуть Reddit, Skype и Instagram.
MariaDB
Изначально MariaDB создавалась сообществом в качестве форка MySQL, когда тот выкупила Oracle. MariaDB все еще свободно распространяется под стандартной универсальной лицензией GNU.
MariaDB создана на базе MySQL с добавлением поддержки еще большего количество движков и исправлением ограничений по хранению данных. Она работает быстрее MySQL и позволяет запускать SQL и NoSQL в одной базе данных.
Среди известных пользователей MariaDB можно выделить Google, Mozilla и Wikimedia Foundation.
SQLite
В отличие от других представителей в этом списке, SQLite не является менеджером баз данных с архитектурой клиент-сервер; он, скорее, встраивается в конечное приложение, благодаря чему мало весит и способен работать с большими массивами систем и платформ.
В SQLite есть некоторые ограничения, поскольку он лишь частично предоставляет триггеры, имеет ограниченную функцию ALTER TABLE и не может записывать в представления. Кроме того, SQLite ограничивает максимальный размер базы до 32 000 столбцов и 140 ТБ.
Получается, что SQLite лучше всего использовать в качестве компонента базы данных для других приложений. Среди известных пользователей можно назвать Google Chrome, Mozilla Firefox, Opera и Safari.
Что такое система управления реляционными базами данных?
Система управления базой данных (СУБД или DBMS) – это программное решение, которое позволяет пользователям просматривать, запрашивать и управлять базами данных.
Система управления реляционными базами данных (РСУБД или RDBMS) – это более расширенное подмножество СУБД для управления реляционными базами данных.
Ниже приведены некоторые различия между универсальной СУБД и РСУБД
СУБД
РСУБД
Хранит меньшее количество данных в виде файлов; нет взаимосвязей
Сохраняет большие объемы данных в виде связанных друг с другом таблиц
Можно обращаться к одному элементу данных за раз
Можно обращаться ко многим элементам данных одновременно.
При работе с большими объемами замедляется получение данных
В реляционном подходе получение данных не замедляется даже для больших БД.
Нет нормализации БД.
Есть нормализация БД.
Не поддерживает распределенные БД
Поддерживает распределенные БД.
Поддержка одного пользователя.
Поддержка нескольких пользователей.
Низкий уровень безопасности
Много уровней безопасности.
Низкие требования к программному и аппаратному обеспечению.
Высокие требования к программному и аппаратному обеспечению
Плюсы и минусы реляционных баз данных
Как и во всех моделях баз данных, здесь есть свои плюсы и минусы.
Плюсы
Реляционные БД используют таблицы столбцов и строк, поэтому они отображают данные проще, чем другие типы, и работать с ними удобнее.
Такая табличная структура создана специально для обработки данных, что повышает производительность и позволяет использовать сложные, высокоуровневые запросы.
И, наконец, в реляционных БД легко масштабировать данные, добавляя строки, столбцы или целые таблицы, не нарушая при этом общей структуры базы.
Минусы
Реляционные БД могут масштабироваться только до определенного предела. Если говорить о размере базы, то в некоторых БД есть строгое ограничение по длине столбцов. Если вы создаете базу на отдельном сервере, то при ее разрастании придется покупать дополнительное место, то есть в долгосрочной перспективе ее поддержание обходится не дешево.
Кроме того, постоянное добавление новых элементов может усложнить базу и затруднить установление связей между новыми частями. Сложные отношения между данными замедляют запросы и негативно сказываются на производительности.
Заключение
После прочтения этой статьи у вас должно появиться четкое понимание того, как работают реляционные базы данных. Также вы познакомились с рядом интересных примеров РСУБД.
Под телефонными (VoIP) кодеками понимаются различные математические модели используемые для цифрового кодирования и компрессирования (сжатия) аудио информации. Многие из современных кодеков используют особенности восприятия человеческим мозгом неполной информации: алгоритмы голосового сжатия пользуются этими особенностями, вследствие чего не полностью услышанная информация полностью интерпретируется головным мозгом. Основным смыслом таких кодеков является сохранение баланса между эффективностью передачи данных и их качеством.
Изначально, термин кодек происходил от сочетания слов КОДирование/ДЕКодирование, то есть устройств, которые преобразовывали аналог в цифровую форму. В современном мире телекоммуникаций, слово кодек скорее берет начало от сочетания КОмпрессия/ДЕКомпрессия.
Перед тем как начать подробный рассказ про различные кодеки, мы составили таблицу со краткой сравнительной характеристикой современных кодеков:
Кодек
Скорость передачи, Кб/сек.
Лицензирование
G.711
64 Кб/сек.
Нет
G.726
16, 24, 32 или 40 Кб/ сек.
Нет
G.729А
8 Кб/ сек.
Да
GSM
13 Кб/ сек.
Нет
iLBC
13.3 Кб/ сек. (30 мс фрейма);
15.2 Кб/ сек. (20 мс фрейма)
Нет
Speex
Диапазон от 2.15 до 22.4 Кб/ сек.
Нет
G.722
64 Кб/сек.
Нет
G.711
Кодек G.711 это самый базовый кодек ТфОП (PSTN). В рамках данного кодека используется импульсно-кодовая модуляция PCM. Всего в мире используется 2 метода компандирования (усиления сигнала) G.711: µ – закон в Северной Америке и A – закон в остальной части мира. Данный кодек передает 8 – битное слово 8 000 раз в секунду. Если умножить 8 на 8 000, то получим 64 000 бит – то есть 64 Кб/с, скорость потока, создаваемого G.711.
Многие люди скажут, что G.711 это кодек, в котором отсутствует компрессирование (сжатие), но это не совсем так: сам по себе процесс компандирования является одной из форм компрессирования. Все мировые кодеки «выросли» на базе G.711.
Важная особенность G.711 в том, что он минимально загружает процессор машины, на которой он запущен.
G.726
Этот кодек использовался некоторое время, став заменой для G.721, который на тот момент устарел, и является одним из первых кодеков с алгоритмом компрессии. Он так же известен как кодек с адаптивной импульсно-кодовой модуляции (Adaptive Differential Pulse-Code Modulation, ADPCM) и может использовать несколько скоростей потока передачи. Наиболее распространенные скорости передачи это 16, 24 и 32 Кб/сек.
Кодек G.726 почти идентичен G.711 – единственным отличием является то, что он использует половину полосы пропускания. Это достигается путем того, что вместо отправки полного результата квантования, он отправляет только разницу между двумя последними измерениями. В 1990 году от кодека практически отказались, так как он не мог работать с факсимильными сигналами и модемами. Но в наше время, из – за своей экономии полосы пропускания и ресурсов центрального процессора у него есть все шансы вновь стать популярные кодеком в современных сетях.
G.729A
Учитывая то, какую малую полосу пропускания использует G.729A, всего 8 Кб/сек., он обеспечивает превосходное качество связи. Это достигается за счет использования сопряженной структуры с управляемым алгебраическим кодом и линейным предсказанием (Conjugate-Structure Algebraic-Code-Excited Linear Prediction, CS-ACELP). По причине патента, использование данного кодека является коммерческим; однако это не мешает кодеку G.729A быть популярным в различных корпоративных сетях и телефонных системах.
Для достижения такой высокой степени сжатия, G.729A активно задействует мощности процессора (CPU).
GSM
Кодек для глобального стандарта цифровой мобильной сотовой связи (Global System for Mobile Communications, GSM) не обременен лицензированием, как его аналог G.729A, но предлагает высокое качество и умеренную нагрузку на процессор при использовании 13 Кб/сек. полосы пропускания. Эксперты считают, что качество GSM несколько ниже чем G.729A.
iLBC
Кодек iLBC (Internet Low Bitrate Codec) сочетает в себе низкое использование полосы пропускания и высокого качества. Данный кодек идеально подходит для поддержания высокого качества связи в сетях с потерями пакетов.
iLBC не так популярен как кодеки стандартов ITU и поэтому, может быть не совместим с популярными IP – телефонами и IP – АТС. Инженерный совет Интернета (IETF) выпустил RFC 3951 и 3952 в поддержку кодека iLBC.
Internet Low Bitrate кодек использует сложные алгоритмы для достижения высокого показателя сжатия, поэтому, весьма ощутимо загружает процессор.
В настоящий момент iLBC используется бесплатно, но владелец этого кодека, Global IP Sound (GIPS), обязует уведомлять пользователей о намерении коммерческого использования этого кодека. Кодек iLBC работает на скорости в 13.3 Кб/сек. с фреймами в 30 мс, и на скорости 15.2 кб/сек. с фреймами в 20 мс.
Speex
Кодек Speex относится к семейству кодеков переменной скорости (variable-bitrate, VBR), что означает возможность кодека динамически менять скорость передачи битов в зависимости от статуса производительности сети передачи. Этот кодек предлагается в широкополосных и узкополосных модификациях, в зависимости от требования к качеству.
Speex полностью бесплатный и распространяется под программной лицензией университета Беркли (Berkeley Software Distribution license, BSD). Кодек работает на диапазонах от 2.15 до 22.4 Кб/сек. в рамках переменного битрейта.
G.722
G.722 является стандартом ITU-T (International Telecommunication Union - Telecommunication sector) и впервые опубликован в 1988 году. Кодек G.722 позволяет обеспечить качество, не ниже G.711 что делает его привлекательным для современных VoIP разработчиков. В настоящий момент патент на G.722 не действителен, и этот кодек является полностью бесплатным.
Выходим на новый уровень. Для изучения следующей темы вы уже должны хорошо понимать связующее дерево. Связующее дерево (Spanning Tree Protocol STP) — это важная тема. Есть много вещей, которые могут пойти не так, и в этой статье мы рассмотрим ряд инструментов, которые мы можем использовать для защиты нашей топологии связующего дерева.
Для профессионалов
PortFast: мы видели это в статье о spanning tree и rapid spanning tree. Он настроит порт доступа как пограничный порт, поэтому он переходит в режим forwarding немедленно.
BPDU Guard: это отключит (err-disable) интерфейс, который имеет настроенный PortFast, если он получает BPDU.
BPDUFilter: это будет подавлять BPDU на интерфейсах.
Root Guard: это предотвратит превращение соседнего коммутатора в корневой мост, даже если он имеет лучший идентификатор моста.
UplinkFast: мы видели это в статье о связующем дереве. Он улучшает время конвергенции.
BackboneFast: мы также видели это в статье о связующем дереве. Оно улучшает время конвергенции, если у вас есть сбой косвенной связи.
UplinkFast и BackboneFast не требуются для rapid spanning tree, поскольку оно уже реализовано по умолчанию. Мы начнем с BPDUguard:
В топологии выше мы имеем идеально работающую топологию остовного дерева. По умолчанию связующее дерево будет отправлять и получать BPDU на всех интерфейсах. В нашем примере у нас есть компьютер, подключенный на интерфейсе fa0/2 коммутатора B. Есть кто-то, кто с враждебными намерениями мог бы запустить инструмент, который сгенерирует BPDU с превосходящим ID моста. Что же произойдет- так это то, что наши коммутаторы будут считать, что корневой мост теперь может быть достигнут через коммутатор B, и у нас будет повторный расчет связующего дерева. Звучит не очень хорошо, правда?
Можно поставить человека (хакера) в середине топологии для атаки так, чтобы никто не знал. Представьте себе, что хакер подключает свой компьютер к двум коммутаторам. Если хакер станет корневым мостом, то весь трафик от коммутатора А или коммутатора C к коммутатору В будет проходить через него. Он запустит Wireshark и подождет, пока произойдет чудо.
BPDUguard гарантирует, что, когда мы получаем BPDU на интерфейс, интерфейс перейдет в режим err-disable.
Чтобы продемонстрировать работу BPDUguard будем использовать два коммутатора. Настроем интерфейс fa0/16 коммутатора B так, что он перейдет в режим err-disable, если он получит BPDU от коммутатора C.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree bpduguard enable
Вот как вы включаете его в интерфейсе. Имейте в виду, что обычно вы никогда не будете делать это между коммутаторами. Вы должны настроить это на интерфейсах в режиме доступа, которые подключаются к компьютерам.
А-а... вот и наш интерфейс.
SwitchB(config-if)#no spanning-tree bpduguard
SwitchB(config-if)#shutdown
SwitchB(config-if)#no shutdown
Избавиться от BPDUguard можно используя команды shut/no shut, чтобы сделать интерфейс снова рабочим.
SwitchB(config)#spanning-tree portfast bpduguard
Вы также можете использовать команду spanning-tree portfast bpduguard. Это позволит глобально активировать BPDUguard на всех интерфейсах, которые имеют включенный portfast.
SwitchB(config)#spanning-tree portfast default
Portfast также может быть включен глобально для всех интерфейсов, работающих в режиме доступа.
Это полезная команда, позволяющая проверить свою конфигурацию. Вы видите, что portfast и BPDUGuard были включены глобально.
BPDUGuard переведет интерфейс в режим err-disable. Кроме того, можно фильтровать сообщения BPDU с помощью BPDUfilter. BPDUfilter может быть настроен глобально или на уровне интерфейса и есть разница:
Глобальный: если вы включите bpdufilter глобально, любой интерфейс с включенным portfast станет стандартным портом.
Интерфейс: если вы включите BPDUfilter на интерфейсе, он будет игнорировать входящие BPDU и не будет отправлять никаких BPDU.
Вы должны быть осторожны, когда включаете BPDUfilter на интерфейсах. Вы можете использовать его на интерфейсах в режиме доступа, которые подключаются к компьютерам, но убедитесь, что вы никогда не настраиваете его на интерфейсах, подключенных к другим коммутаторам. Если вы это сделаете, вы можете получить цикл.
Для демонстрации работы BPDUfilter мы будем снова использовать коммутатор B и коммутатор C.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree portfast trunk
SwitchB(config-if)#spanning-tree bpdufilter enable
Он перестанет посылать BPDU и будет игнорировать все, что будет получено.
SwitchB#debug spanning-tree bpdu
Вы не увидите никаких интересных сообщений, но если вы включите отладку BPDU, то заметите, что он больше не отправляет никаких BPDU. Если вы хотите, вы также можете включить отладку BPDU на коммутаторе C, и вы увидите, что нет ничего от коммутатора B.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#no spanning-tree bpdufilter enable
Давайте избавимся от команды BPDUfilter на уровне интерфейса.
SwitchB(config)#spanning-tree portfast bpdufilter default
Вы также можете использовать глобальную команду для BPDUfilter. Это позволит включить BPDUfilter на всех интерфейсах, которые имеют portfast.
Еще один вариант, с помощью которого мы можем защитить наше связующее дерево, - это использовать RootGuard. Проще говоря, RootGuard позаботится о том, чтобы вы не принимали определенный коммутатор в качестве корневого моста. BPDU отправляются и обрабатываются нормально, но, если коммутатор внезапно отправляет BPDU с идентификатором верхнего моста, вы не будете принимать его в качестве корневого моста. Обычно коммутатор D становится корневым мостом, потому что у него есть лучший идентификатор моста, к счастью, у нас есть RootGuard на коммутатое C, так что этого не произойдет!
Рассмотрим с вами конфигурацию с коммутатором B и коммутатором C.
SwitchB(config)#spanning-tree vlan 1 priority 4096
Давайте убедимся, что коммутатор C не является корневым мостом.
Вот как мы включаем RootGuard на интерфейсе.
SwitchB#debug spanning-tree events
Spanning Tree event debugging is on
Не забудьте включить отладку, если вы хотите увидеть события.
SwitchC(config)#spanning-tree vlan 1 priority 0
Давайте перенастроим коммутатор B, изменив приоритет на наименьшее возможное значение 0 на коммутаторе C. Он теперь должен стать корневым мостом.
Вот так коммутатор B не будет принимать коммутатор C в качестве корневого моста. Это заблокирует интерфейс для этой VLAN.
Вот еще одна полезная команда, чтобы проверить, работает ли RootGuard.
Связующее дерево становится все более безопасным с каждой минутой! Однако есть еще одна вещь, о которой мы должны подумать…
Если вы когда-либо использовали волоконные кабели, вы могли бы заметить, что существует другой разъем для передачи и приема трафика. Если один из кабелей (передающий или принимающий) выйдет из строя, мы получим однонаправленный сбой связи, и это может привести к петлям связующего дерева. Существует два протокола, которые могут решить эту проблему:
LoopGuard
UDLD
Давайте начнем с того, что внимательно рассмотрим, что произойдет, если у нас произойдет сбой однонаправленной связи.
Представьте себе, что между коммутаторами волоконно-оптические соединения. На самом деле имеется другой разъем для передачи и приема. Коммутатор C получает BPDU от коммутатора B, и в результате интерфейс стал альтернативным портом и находится в режиме блокировки.
Теперь что-то идет не так... transmit коннектор на коммутаторе B к коммутатору C был съеден мышами. В результате коммутатор C не получает никаких BPDU от коммутатора B, но он все еще может отправлять трафик для переключения между ними.
Поскольку коммутатор C больше не получает BPDU на свой альтернативный порт, он перейдет в forwarding режим. Теперь у нас есть one way loop (петля в один конец), как указано зеленой стрелкой.
Один из методов, который мы можем использовать для решения нашего однонаправленного сбоя связи — это настройка LoopGuard. Когда коммутатор отправляет, но не получает BPDU на интерфейсе, LoopGuard поместит интерфейс в состояние несогласованности цикла и заблокирует весь трафик!
Мы снова будем использовать эту топологию для демонстрации LoopGuard.
SwitchA(config)#spanning-tree loopguard default
SwitchB(config)#spanning-tree loopguard default
SwitchC(config)#spanning-tree loopguard default
Используйте команду spanning-tree loopguard по умолчанию, чтобы включить LoopGuard глобально
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree portfast trunk
SwitchB(config-if)#spanning-tree bpdufilter enable
В примере у нас нет никаких волоконных разъемов, поэтому мы не сможем создать однонаправленный сбой связи. Однако мы можем смоделировать его с помощью BPDUfilter на интерфейсе SwitchB fa0/16. Коммутатор C больше не будет получать никаких BPDU на свой альтернативный порт, что заставит его перейти в режим переадресации.
Обычно это вызвало бы петлю, но, к счастью, у нас есть настроенный LoopGuard. Вы можете увидеть это сообщение об ошибке, появляющееся в вашей консоли. Проблема решена!
SwitchC(config-if)#spanning-tree guard loop
Если вы не хотите настраивать LoopGuard глобально, вы т можете сделать это на уровне интерфейса.
Другой протокол, который мы можем использовать для борьбы с однонаправленными сбоями связи, называется UDLD (UniDirectional Link Detection). Этот протокол не является частью инструментария связующего дерева, но он помогает нам предотвратить циклы.
Проще говоря, UDLD — это протокол второго уровня, который работает как механизм keepalive. Вы посылаете приветственные сообщения, вы их получаете, и все прекрасно. Как только вы все еще посылаете приветственные сообщения, но больше их не получаете, вы понимаете, что что-то не так, и мы блокируем интерфейс.
Убедитесь, что вы отключили LoopGuard перед работой с UDLD. Мы будем использовать ту же топологию для демонстрации UDLD.
Существует несколько способов настройки UDLD. Вы можете сделать это глобально с помощью команды udld, но это активирует только UDLD для оптоволоконных линий связи! Существует два варианта для UDLD:
Normal (default)
Aggressive
Когда вы устанавливаете UDLD в нормальное состояние, он помечает порт как неопределенный, но не закрывает интерфейс, когда что-то не так. Это используется только для того, чтобы «информировать» вас, но это не предотвратит циклы.
Агрессивный - это лучшее решение, когда пропадает связь с соседом. Он будет посылать кадр UDLD 8 раз в секунду. Если сосед не отвечает, интерфейс будет переведен в режим errdisable.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#udld port aggressive
SwitchC(config)#interface fa0/16
SwitchC(config-if)#udld port aggressive
Мы будем использовать коммутатор B и C, чтобы продемонстрировать UDLD. Будем использовать агрессивный режим, чтобы мы могли видеть, что интерфейс отключается, когда что-то не так.
Если вы хотите увидеть, что UDLD работает, вы можете попробовать выполнить отладку.
Теперь самое сложное будет имитировать однонаправленный сбой связи. LoopGuard был проще, потому что он был основан на BPDUs. UDLD запускает свой собственный протокол уровня 2, используя собственный MAC-адрес 0100.0ccc.сссс.
SwitchC(config)#mac access-list extended UDLD-FILTER
SwitchC(config-ext-macl)#deny any host 0100.0ccc.cccc
SwitchC(config-ext-macl)#permit any any
SwitchC(config-ext-macl)#exit
SwitchC(config)#interface fa0/16
SwitchC(config-if)#mac access-group UDLD-FILTER in
Это творческий способ создавать проблемы. При фильтрации MAC-адреса UDLD он будет думать, что существует сбой однонаправленной связи!
Вы увидите много отладочной информации, но конечным результатом будет то, что порт теперь находится в состоянии err-disable.
Вы можете проверить это с помощью команды show udld.
LoopGuard и UDLD решают одну и ту же проблему: однонаправленные сбои связи.
Они частично пересекаются, но есть ряд различий, вот общий обзор:
LoopGuardUDLDНастройкиГлобально/на портуГлобально (для оптики)/на портуVLAN?ДаНет, на портуАвтосохранениеДаДа, но вам нужно настроить errdisable timeout.Защита от сбоев STP из-за однонаправленных связейДа - нужно включить его на всех корневых и альтернативных портахДа - нужно включить его на всех интерфейсах.Защита от сбоев STP из-за сбоев программного обеспечения (нет отправки BPDU)ДаНетЗащита от неправильного подключения (коммутационный оптический приемопередающий разъем)НетДа
Есть еще одна последняя тема, которую хотелось бы объяснить, это не протокол связующего дерева, но речь идет о избыточных ссылках, поэтому я оставлю ее здесь. Это называется FlexLinks.
Вот в чем дело: при настройке FlexLinks у вас будет активный и резервный интерфейс. Мы настроим это на коммутаторе C:
Fa0/14 будет активным интерфейсом.
Fa0/16 будет интерфейс резервного копирования (этот блокируется!).
При настройке интерфейсов в качестве FlexLinks они не будут отправлять BPDU. Нет никакого способа обнаружить петли, потому что мы не запускаем на них связующее дерево. Всякий раз, когда наш активный интерфейс выходит из строя, резервный интерфейс заменяет его.
SwitchC(config)#interface fa0/14
SwitchC(config-if)#switchport backup interface fa0/16
Именно так мы делаем интерфейс fa0/16 резервной копией интерфейса fa0/14.
Вы можете видеть, что связующее дерево отключается для этих интерфейсов.
Проверьте нашу конфигурацию с помощью команды show interfaces switchport backup. Вот и все, что нужно было сделать. Это интересное решение, потому что нам больше не нужно связующее дерево. Ведь в любой момент времени активен только один интерфейс.
SwitchC(config)#interface f0/14
SwitchC(config-if)#shutdown
Давайте закроем активный интерфейс.
Вы можете видеть, что fa0/16 стал активным. Вот и все.