По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В 2013 году была опубликована версия OSPF для маршрутизации IPv6. Известный как OSPFv3, он был первоначально указан в RFC 2740, который позже был заменен на RFC 5340 и обновлен более поздними стандартами.
Маршаллинг данных в OSPF
Как и многие другие протоколы, разработанные на заре проектирования сетей, OSPF был разработан для минимизации вычислительной мощности, памяти и полосы пропускания, необходимых для передачи информации о маршрутизации IPv4 по сети. Два конкретных выбора, сделанных на ранних этапах процесса проектирования OSPF, отражают эту озабоченность по поводу использования ресурсов:
OSPF использует поля фиксированной длины для упорядочивания данных, а не TLV. Это экономит накладные расходы на перенос дополнительных метаданных в виде заголовков Type Length Value (TLV), снижает требования к обработке, позволяя сопоставлять структуры данных фиксированного размера в памяти с пакетами по мере их приема с канала связи, и уменьшает размер данных OSPF на линии.
OSPF разбивает базу данных топологии на несколько типов данных, а не полагается на один LSP с TLV. Это означает, что каждый вид информации - доступность, топология и т. д. - передается в уникальном формате пакета.
Каждый тип информации, которую OSPF может нести, переносится в разном типе Link State Advertisement (LSA). Вот некоторые из наиболее примечательных типов LSA:
Тип 1: код 0x2001, Router LSA
Тип 2: код 0x2002, Network LSA
Тип 3: код 0x2003, Inter-Area Prefix LSA
Тип 4: код 0x2004, Inter-Area Router LSA
Тип 5: код 0x4005, AS-external LSA
Тип 7: код 0x2007, Type-7 (NSSA) LSA
Существует ряд других типов LSA, включая непрозрачные данные, членство в группе многоадресной рассылки и LSA с лавинной рассылкой (например, для одного соседа, одного канала или одного домена лавинной рассылки).
Каждый маршрутизатор OSPF генерирует ровно один Router LSA (тип 1). Этот LSA описывает любых соседей, примыкающих к объявляемому маршрутизатору, а также любые подключенные достижимые пункты назначения. Состояние каналов связи на этих соседей и пунктов назначения определяется из объявления соседей и пункта назначения. Несмотря на фразу «состояние канала», каналы не объявляются как отдельная «вещь» (это часто вызывает путаницу). Если Router LSA становится слишком большим, чтобы поместиться в один IP-пакет (из-за MTU канала), он будет разделен на несколько IP-фрагментов для передачи от маршрутизатора к маршрутизатору. Каждый маршрутизатор повторно собирает весь Router LSA перед его локальной обработкой и лавинно рассылает весь Router LSA, если он изменяется.
OSPF также использует несколько разных типов пакетов - они не совпадают с типами LSA. Скорее, их можно рассматривать как разные «службы» в OSPF или, возможно, как разные «номера портов», выполняемые поверх протокола User Datagram Protocol (UDP) или протокола Transmission Control Protocol (TCP).
Hello - это тип 1. Они используются для обнаружения и сохранения соседей.
Database Descriptor (DBD) относится к типу 2. Они используются для описания таблицы локальной топологии.
Link State Request (LSR) относится к типу 3. Они используются для запроса определенных объявлений состояния канала от соседнего маршрутизатора.
Link State Update (LSU) относится к типу 4. Они используются для передачи объявлений состояния канала.
Link State Acknowledgment - это тип 5. Это просто список заголовков LSA. Любой LSA, указанный в этом пакете, подтверждается как полученный передающим маршрутизатором.
Обнаружение соседей и топологии
В качестве протокола состояния канала OSPF должен гарантировать, что каждый маршрутизатор в пределах области (flooding domain) имеет одну и ту же базу данных для расчета loop-free путей. Любое изменение в базе данных общей топологии может привести к возникновению зацикливания маршрутизации, который будет длиться до тех пор, пока существует изменение в базе данных общей топологии. Таким образом, одной из целей формирования соседей OSPF является обеспечение надежной flooding рассылки информации о топологии через сеть. Вторая причина формирования соседей OSPF - обнаружение топологии сети путем определения того, какие маршрутизаторы находятся рядом с локальным маршрутизатором. На рисунке 1 показан процесс формирования соседей OSPF.
На рисунке 1:
B отправляет пакет приветствия к A.
Поскольку приветствие B содержит пустой список видимых соседей, A переводит B в состояние инициализации и добавляет B в список видимых соседей.
A передает приветствие B в списке видимых соседей.
B получает приветствие от A и отправляет приветствие с A в списке видимых соседей.
A получает это приветствие. Поскольку сам A находится в списке соседей, A помещает B в двустороннее состояние. Это означает, что A проверил наличие двусторонней связи между собой и B.
Если по этой линии избираются DR и BDR, то выборы происходят после шага 5. Как только выборы завершены, DR и BDR переводятся в состояние exstart. Во время этого состояния ведущий и ведомый выбираются для обмена DBDS и LSA. По сути, мастер управляет потоком DBDS и LSA между новыми соседними маршрутизаторами. Соседние маршрутизаторы на канале point-to-point технически переходят непосредственно в состояние full state в этой точке.
B переведен в состояние обмена.
A отправляет B набор DBD с описанием своей базы данных. B отправляет набор DBD с описанием своей базы данных в A.
A отправляет запрос состояния канала B для каждого LSA, описанного B, и A не имеет его копии в своей локальной таблице топологии.
B отправляет LSA для каждого запроса Link State (LS) от A.
11. Как только базы данных синхронизируются, B переводится в full state.
Процесс формирования соседей OSPF проверяет MTU на обоих концах линии связи, передавая MTU исходящего интерфейса в hello сообщении. Если два hello-пакета не совпадают по размеру MTU, два маршрутизатора OSPF не образуют смежности.
Надежная лавинная рассылка.
OSPF должен не только гарантировать завершение первоначального обмена информацией о топологии, но также гарантировать, что текущие изменения в топологии сети будут переданы на каждый маршрутизатор во flooding domain. На рисунке 2 показан заголовок LSA OSPF. Изучение этого заголовка поможет нам понять, как OSPF надежно массово рассылает информацию о топологии и доступности через сеть.
На рисунке 2:
LS Age - это (примерно) количество секунд с момента создания Link State Advertisement. Это число идет увеличивается, а не уменьшается. Когда LS Age достигает значения MAXAGE (на любом маршрутизаторе, а не только на исходном маршрутизаторе), маршрутизатор увеличивает порядковый номер на 1, устанавливает для LS Age максимальное число и повторно загружает LSA по всей сети. Это позволяет удалить старую информацию о топологии и доступности, которая не обновлялась некоторое время. Маршрутизатор, который инициирует какой-либо конкретный LSA, обновит свои LSA за некоторое количество секунд до того, как это поле LSA Age достигнет максимума- это интервал обновления LS.
Link State Identifier - это уникальный идентификатор, присвоенный исходным маршрутизатором для описания этого LSA. Обычно это адрес канала или какой-либо адрес локального уровня канала (например, Ethernet Media Access Control (MAC-адрес).
Advertising Router - это идентификатор маршрутизатора-отправителя. Его часто путают с IP-адресом, поскольку он часто является производным от локально настроенного IP-адреса, но это не IP-адрес.
Link State Sequence Number указывает версию LSA. Как правило, более высокие числа означают более новые версии, хотя существуют более ранние версии OSPF, в которых используется круговое числовое пространство, а не абсолютно увеличивающееся. Реализации, которые используют абсолютно увеличивающееся числовое пространство, перезапускают процесс OSPF, если достигнут конец числового пространства.
Link State Checksum - это контрольная сумма, вычисляемая для LSA, используемая для обнаружения ошибок при передаче или хранении информации.
Рисунок 3 используется для изучения процесса flooding рассылки.
На рисунке 3:
Линия связи на 2001: db8: 3e8: 100 :: / 64 настроена, запущена, подключена и т. д.
A перестраивает свой Router LSA (тип 1), чтобы включить эту новую информацию о доступности, упаковывает его в LSU (который может быть фрагментирован при размещении в IP-пакеты) и лавинно рассылает его B.
B получает это LSA и подтверждает его получение подтверждением состояния канала (link state acknowledgment). A повторно отправит LSA, если B не подтвердит его достаточно быстро.
Теперь B проверит свою таблицу топологии, чтобы определить, является ли этот LSA новым или копией уже имеющегося. B определяет это в первую очередь путем изучения порядкового номера, включенного в сам LSA. Если это новый (или обновленный) LSA, B инициирует тот же процесс для лавинной рассылки измененного LSA в C.
Подведение итогов об OSPF
OSPF можно описать как:
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол)
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в домене лавинной рассылки (протокол состояния канала)
Расчет путей без петель с использованием алгоритма SPF Дейкстры
Проверка двусторонней связи при формировании соседей путем переноса списка «видимых соседей» в своих пакетах приветствия.
Проверка MTU при формировании смежности путем переноса MTU в приветственном пакете
OSPF широко используется в малых и крупных сетях, включая розничную торговлю, поставщиков услуг, финансовые и многие другие предприятия.
Общие элементы OSPF и IS-IS
В предыдущих лекциях были рассмотрены аспекты, отличающие OSPF и IS-IS друг от друга. Однако есть ряд вещей, которые OSPF и IS-IS реализовали достаточно схожими способами, чтобы рассматривать их решения как простые варианты. К ним относятся обработка каналов с множественным доступом, концепция Shortest Path Tree и способ way two-way.
Каналы с множественным доступом
Каналы с множественным доступом, такие как Ethernet, - это каналы, по которым подключенные устройства «совместно используют» доступную полосу пропускания, и каждое устройство может отправлять пакеты напрямую любому другому устройству, подключенному к тому же каналу. Каналы с множественным доступом создают особые проблемы для протоколов, которые синхронизируют базу данных по каналу.
Рассмотрим рисунок 3 для понимания.
Один из вариантов, который протокол может использовать при работе по каналу с множественным доступом, - это просто сформировать смежности, как это обычно происходит по каналу «точка-точка» (point-to-point). Например, на рисунке 3:
A может образовывать смежность с B, C и D.
B может образовывать смежность с A, C и D.
C может образовывать смежность с A, B и D.
D может образовывать смежность с A, B и C
Если используется этот шаблон формирования смежности, когда A получает новый фрагмент LSP (IS-IS) или LSA (OSPF) от некоторого маршрутизатора, не подключенного к совместно используемому каналу:
A передаст новый фрагмент или LSA по отдельности B, C и D.
Когда B получает фрагмент или LSA, он передаст новый фрагмент или LSA в C и D отдельно.
Когда C получает фрагмент или LSA, он передает новый фрагмент или LSA D.
Учитывая передачу каждого фрагмента или LSA, а также следующий CSNP или подтверждение, чтобы гарантировать синхронизацию локальной базы данных на каждом маршрутизаторе, большое количество пакетов должно пересекать совместно используемый канал, чтобы гарантировать синхронизацию базы данных каждого устройства. Чтобы уменьшить переполнение каналов множественного доступа, IS-IS и OSPF выбирают одно устройство, которое отвечает за обеспечение того, чтобы каждое устройство, подключенное к каналу, имело синхронизированную базу данных. На рисунке 3 для IS-IS:
Одно устройство выбрано для управления лавинной рассылкой по каналу. В IS-IS это устройство называется выделенной промежуточной системой (Designated Intermediate System - DIS).
Каждое устройство с новой информацией о состоянии канала отправляет фрагмент на адрес многоадресной рассылки, чтобы каждое устройство в общем канале получило его. Ни одно из устройств, подключенных к каналу, не отправляет никаких подтверждений при получении обновленного фрагмента.
DIS регулярно отправляет копию своего CSNP на один и тот же адрес многоадресной рассылки, поэтому каждое устройство в канале множественного доступа получает его копию.
Если какое-либо устройство на общем канале обнаружит, что в нем отсутствует какой-то конкретный фрагмент, на основе описания базы данных DIS в CSNP, оно отправит PSNP в канал, запрашивая недостающую информацию.
Если какое-либо устройство в общем канале обнаружит, что у него есть информация, которой нет у DIS, на основе описания базы данных DIS в CSNP, оно перенаправит недостающий фрагмент в канал.
Таким образом, новая информация о состоянии канала передается по линии минимальное количество раз. На рисунке 3 для OSPF:
Для управления лавинной рассылкой по каналу выбирается одно устройство, называемое назначенным маршрутизатором (Designated Router - DR). Также выбирается резервное устройство, называемое резервным назначенным маршрутизатором (Backup Designated Router - BDR).
Каждое устройство с новой информацией о состоянии канала пересылает ее на специальный адрес многоадресной рассылки, контролируемый DR и BDR (маршрутизаторами, работающими только как DR).
DR получает этот LSA, проверяет его, чтобы определить, содержит ли он новую информацию, а затем повторно загружает его на многоадресный адрес, который прослушивают все маршрутизаторы OSPF на канале (все маршрутизаторы SPF).
Однако выбор DIS или DR не влияет только на лавинную передачу информации по каналу множественного доступа. Это также влияет на способ вычисления SPF через канал. Рисунок 4 показывает это.
На рисунке 4 A выбран в качестве DIS или DR для схемы множественного доступа. A не только гарантирует, что каждое устройство в канале имеет синхронизированную базу данных, но также создает псевдоузел или p-узел и объявляет его, как если бы это было реальное устройство, подключенное к сети. Каждый из маршрутизаторов, подключенных к совместно используемому каналу, объявляет о возможности подключения к p-узлу, а не к каждой из других подключенных систем.
В IS-IS A создает LSP для p-узла. Этот p-узел объявляет канал с нулевой стоимостью обратно каждому устройству, подключенному к каналу множественного доступа. В OSPF A создает Network LSA (тип 2).
Без этого p-узла сеть выглядит как full mesh (полная сетка) для других промежуточных систем в домене лавинной рассылки, как показано в левой части рисунка 4. С p-узлом сеть выглядит как hub-and-spoke с p-узлом в качестве концентратора. Каждое устройство объявляет канал на p-узел, при этом стоимость канала устанавливается равной стоимости локального интерфейса для совместно используемого канала. В свою очередь p-узел возвращает канал с нулевой стоимостью обратно на каждое устройство, подключенное к общему каналу. Это снижает сложность вычисления SPF для крупномасштабных каналов с множественным доступом.
Концептуализация связей, узлов и достижимости в протоколах состояний каналов
Один сбивающий с толку аспект протоколов состояния каналов - это то, как узлы, каналы и достижимость взаимодействуют друг с другом. Рассмотрим рисунок 5.
И в OSPF, и в IS-IS узлы и каналы используются как Shortest Path Tree, как показано более темными сплошными линиями. Пунктирные линии показывают, как информация о доступности прикрепляется к каждому узлу. Каждый узел, подключенный к конкретному достижимому пункту назначения, объявляет пункт назначения - не только один из двух узлов, подключенных к каналу точка-точка, но и оба. Почему так?
Основная причина в том, что это просто самое простое решение для объявления доступных мест назначения. Если вы хотите создать протокол маршрутизации, который объявлял бы каждое достижимое назначение только как подключенное к одному устройству, вам нужно было бы найти способ выбрать, какое из подключенных устройств должно объявлять достижимое назначение. Кроме того, если выбранное устройство выйдет из строя, то какое-то другое устройство должно взять на себя объявление достижимого пункта назначения, что может занять время и негативно повлиять на конвергенцию. Наконец, позволяя каждому устройству объявлять о доступности для всех подключенных пунктов назначения, вы фактически можете найти кратчайший путь к каждому пункту назначения.
Проверка двустороннего подключения в SPF
Двусторонняя связь является проблемой для плоскостей управления в двух разных местах: между соседними устройствами и при вычислении путей без петель через сеть. И IS-IS, и OSPF также обеспечивают двустороннюю связь при вычислении путей без петель.
Существенным элементом является проверка обратной связи.
Рисунок 6 используется для демонстрации этого.
На рисунке 6 направление каждого звена обозначено стрелкой (или набором стрелок). Связь [A,B] является однонаправленной по отношению к A. Остальные связи являются двусторонними (двунаправленными). При вычислении SPF D будет делать следующее:
При обработке информации о состоянии связи C обратите внимание, что C утверждает, что он подключен к B. D найдет информацию о состоянии связи B и проверит, чтобы убедиться, что B также утверждает, что он подключен к C. В этом случае B действительно утверждает, что подключен к C, поэтому D будет использовать канал [B, C].
При обработке информации о состоянии связи B обратите внимание, что B утверждает, что он подключен к A. Однако, изучая информацию о состоянии связи A, D не может найти никакой информации от A, утверждающего, что он подключен к B. Из-за этого D не будет использовать канал [A, B].
Эта проверка обычно выполняется либо до того, как линия связи будет перемещена в TENT, либо до того, как линия связи будет перемещена из TENT в PATH.
Предыдущая статья этого цикла:
Устранение неполадок коммутации Cisco
Следующая статья этого цикла:
Устранение неисправностей EtherChannel
Case #1
На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.
Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:
Выбирается интерфейс, который имеет самую низкую стоимость для корневого моста.
Если стоимость равная, выбирается наименьший номер интерфейса. Обычно стоимость интерфейса Ethernet выше, чем Fast Ethernet, поэтому он должен выбрать интерфейс FastEthernet.
Почему коммутатор выбрал интерфейс Ethernet 0/13?
Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.
После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).
SwitchC(config)#interface Ethernet 0/13
SwitchC(config-if)#no spanning-tree cost 19
Уберем настройки команды cost.
После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!
Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.
Case #2
Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:
Хм, интересно... Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.
Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?
Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).
Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.
Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:
Для VLAN 10 нет активных интерфейсов.
Spanning-дерево было отключено для VLAN 10.
Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально?
SwitchC(config)#spanning-tree vlan 10
Вот так выглядит лучше! Теперь связующее дерево включено для VLAN 10 и работает ... проблема решена! Эта проблема может показаться немного странной, но она появляется ее время от времени в реальном мире. Сценарий, который мы рассмотрели раньше, - это событие из реальной жизни, где клиент, которому поставщик беспроводной связи отключил остовное дерево для интерфейсов, которые подключаются к точке беспроводного доступа. Ниже то, что клиент ввел на коммутаторе:
SwitchC(config)#interface fa0/1
SwitchC(config-if)#no spanning-tree vlan 10
SwitchC(config)#
В интерфейсе они набрали no spanning-tree vlan 10, но как вы видите, что они оказались в режиме глобальной конфигурации. Нет команды для отключения остовного дерева на интерфейсе, подобного этой, поэтому коммутатор думает, что вы ввели глобальную команду для отключения остовного дерева. Коммутатор принимает команду отключения остовного дерева для VLAN 10 и возвращает вас в режим глобальной конфигурации... проблема решена!
Извлеченный урок: проверьте, включено ли связующее дерево.
Case #3
Давайте продолжим по другому сценарию! Та же топология... наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:
Посмотрите на картинку выше. Видите ли вы, что интерфейс FastEthernet 0/16 на коммутаторе B и коммутаторе C обозначены? На Коммутаторе A все интерфейсы обозначены. Как вы думаете, что произойдет, когда один из наших коммутаторов переадресует трансляцию или должен передать кадр? Правильно! У нас будет цикл ...
Обычно в этой топологии интерфейсы FastEthernet 0/16 и 0/17 на коммутаторе C должны быть альтернативными портами, поскольку коммутатор C имеет худший ID моста. Так как они оба обозначены, мы предполагаем, что Коммутатор C не получает BPDU на этих интерфейсах.
Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?
SwitchA#show vlan access-map
SwitchB#show vlan access-map
SwitchC#show vlan access-map
Ни на одном из коммутаторов нет VLAN access maps.
SwitchA#show access-lists
SwitchB#show access-lists
SwitchC#show access-lists
Нет списков доступа...
Нет port security... как насчет команд, связанных с остовным деревом?
Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#no spanning-tree bpdufilter enable
SwitchB(config-if)#interface fa0/17
SwitchB(config-if)#no spanning-tree bpdufilter enable
Удалим настройки фильтра BPDU.
Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель... проблема решена!
Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.
Case #4
Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.
После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.
Используем команду show spanning-tree interface, чтобы проверить информацию о spanning-tree для каждого интерфейса. Как вы можете видеть, существует только связующее дерево для VLAN 1, активное на интерфейсе FastEthernet 0/13 и 0/14.
Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:
Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.
Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#switchport mode trunk
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#switchport mode trunk
Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.
Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!
Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.
В следующей статье мы расскажем, как траблшутить проблемы с EtherChannel.
Когда мы только начинаем изучать Python, мы закладываем некоторые вредные привычки при написании кода, о которых мы можем даже не подозревать.
Вы можете написать код, который сработает сейчас, но может не сработать в будущем, или вы можете использовать какие-то хитрые ходы вместо встроенной функции, которая могла бы облегчить вашу жизнь.
У большинства из нас сохранились не одна из тех вредных привычек при программировании на Python, что формируются в период первых месяцев обучения. Отличная новость в том, что вы можете с легкостью искоренить их, прочитав приведенный ниже текст.
1. Использование import *
Каждый раз, когда нам становится лень, то возникает соблазн импортировать все необходимое из модуля с помощью from xyz import *.
Это не самый лучший подход по многим причинам. Кот несколько из них:
Это может оказаться неэффективно: если в модуле очень много объектов, то вам придется долго ждать, пока все импортируется.
Это может вызвать конфликт имен переменных: когда вы используете *, то вы понятия не имеете, какие объекты вы импортируете и как они называются.
Как же с этим бороться? Импортируйте либо какой-то конкретный объект, либо весь модуль целиком.
# Using import *
# Bad
from math import *
print(floor(2.4))
print(ceil(2.4))
print(pi)
# Good
import math
from math import pi
print(math.floor(2.4))
print(math.ceil(2.4))
print(pi)
2. Try/except: отсутствие указания исключения в блоке «except»
Я очень долго пренебрегал этим. Сложно посчитать, сколько раз Pycharm давал мне понять (этими противными подчеркиваниями), что не нужно использовать «голое» исключение. Это идет в разрез с рекомендациями PEP8.
# Try - except
# Bad
try:
driver.find_element(...)
except:
print("Which exception?")
# Good
try:
driver.find_element(...)
except NoSuchElementException:
print("It's giving NoSuchElementException")
except ElementClickInterceptedException:
print("It's giving ElementClickInterceptedException")
Проблема «голых» исключений заключается в том, что оно будет перехватывать исключения SystemExit и KeyboardInterrupt, что затрудняет прерывание программы с помощью Control-C.
В следующий раз, когда вы будете использовать try/except, укажите исключение в блоке except.
3. Не использовать Numpy для математических вычислений
Очень часто мы забываем, что в Python есть множество пакетов, которые могут значительно облегчить нашу жизнь и сделать ее более продуктивной.
Одним из таких пакетов является Numpy – пакет для математических вычислений. Numpy может помочь вам вычислять математические операции быстрее, чем циклы for.
Допустим, что у нас есть массив random_scores, и мы хотим получить средний балл тех, кто не сдал экзамен (score>>dict_countries.keys()
dict_keys(['USA', 'UK', 'Canada'])>>>dict_countries.values()
dict_values([329.5, 67.2, 38])
Проблема тут заключается в том, что мы не всегда используем их должным образом.
Например, мы хотим просмотреть словарь и получить ключи. Вы можете использовать метод .keys, но знаете ли вы, что ключи можно получить, просто перебирая словарь? В этом случае использование метода .keys будет излишним.
# Not using .keys() properly
# Bad
for key in dict_countries.keys():
print(key)
# Good
for key in dict_countries:
print(key)
Кроме того, можно придумать некоторые хитрости для получения значений словаря, например, с помощью метода .items().
# Not using .items()
# Bad
for key in dict_countries:
print(dict_countries[key])
# Good
for key, value in dict_countries.items():
print(key)
print(value)
7. Никогда не использовать генераторы (или использовать их всегда)
Генератор предлагает более простой синтаксис при создании новой последовательности (списка, словаря и т.д.) на основе уже определенной последовательности.
Допустим, мы хотим перевести все элементы в нашем списке countries в нижний регистр.
И хотя вы могли бы это сделать просто с помощью цикла for, но также вы можете упростить работу при помощи генератора списка.
# Bad
countries = ['USA', 'UK', 'Canada']
lower_case = []
for country in countries:
lower_case.append(country.lower())
# Good (but don't overuse it!)
lower_case = [country.lower() for country in countries]
Генераторы – это очень полезно, но не злоупотребляйте ими! Помните правило Дзен Python: «Простое лучше, чем сложное».
8. Использование range(len())
Одни из первых функций, которые мы изучили будучи новичками – это range и len, поэтому не удивительно, почему многие люди имеют дурную привычку писать range(len()) при переборе списков.
Допустим у нас есть два списка: countries и populations. Если мы хотим пройтись по обоим спискам одновременно, то, вероятнее всего, вы воспользуетесь range(len()).
# Using range(len())
countries = ['USA', 'UK', 'Canada']
populations = [329.5, 67.2, 38]
# Bad
for i in range(len(countries)):
country = countries[i]
population = populations[i]
print(f'{country} has a population of {population} million people')
И хотя это в принципе выполняет свою работу, вы все равно можете упростить задачу, воспользовавшись enumerate (или, что еще лучше, воспользовавшись функцией zip для сопряжения элементов из обоих списков).
# OK
for i, country in enumerate(countries):
population = populations[i]
print(f'{country} has a population of {population} million people')
# Much Better
for country, population in zip(countries, populations):
print(f'{country} has a population of {population} million people')
9. Форматирование с помощью оператора +
Вероятно, одна из первых вещей, которую мы изучаем в Python, - это то, как соединять строки с помощью оператора +.
Это полезный, но не самый эффективный способ соединения строк в Python. Помимо этого, это не очень красиво – чем больше строк вам нужно соединить, тем больше операторов + вы будете использовать.
Вместо этого вы можете воспользоваться f-строкой.
# Formatting with + operator
# Bad
name = input("Introduce Name: ")
print("Good Morning, " + name + "!")
# Good
name = input("Introduce Name: ")
print(f'Good Morning, {name}')
Преимуществом f-строк в том, что они полезны не только для конкатенации, но и для других целей.
10. Использование изменяемых значений в качестве значений по умолчанию
Если вы включите изменяемое значение (например, список) в качестве параметра функции по умолчанию, то увидите нечто неожиданное.
# Bad
def my_function(i, my_list=[]):
my_list.append(i)
return my_list>>> my_function(1)
[1]
>>> my_function(2)
[1, 2]
>>> my_function(3)
[1, 2, 3]
В приведенном выше коде каждый раз, когда мы вызываем функцию my_function, список my_list сохраняет значения из предыдущих вызовов (а мы, скорее всего, хотим инициировать пустой список при каждом вызове функции).
Чтобы избежать такой проблемы, мы должны установить этот параметр my_list равным None и добавить условие if как показано ниже.
# Good
def my_function(i, my_list=None):
if my_list is None:
my_list = []
my_list.append(i)
return my_list>>> my_function(1)
[1]
>>> my_function(2)
[2]
>>> my_function(3)
[3]