Устранять ошибки коммутации

Часть 1   Часть 2   Часть 3

Содержание

Распространенные проблемы портов и интерфейсов
     Состояние порта или интерфейса – Disable или Shutdown
     Порт или интерфейс в состоянии «errDisable»
     Порт или интерфейс в неактивном состоянии
     Увеличение значения счетчика отложенных кадров в интерфейсе коммутаторов Catalyst
     Перемежающиеся сбои при выполнении функции set timer [значение] from vlan [№ vlan]
     Несоответствие режима магистрального соединения
     Кадры jumbo, giant и baby giant
     Не удается проверить связь с конечным устройством
     Использование команды Set Port Host или Switchport Host для устранения задержек во время запуска
     Проблемы со скоростью/дуплексным режимом, автоматическим согласованием или сетевой платой
     Петли в дереве STP
     UDLD: одностороннее соединение
     Отложенные кадры (Out-Lost или Out-Discard)
     Неполадки программного обеспечения
     Ошибки оборудования
     Ошибки ввода в интерфейсе уровня 3, подключенном к коммутационному порту уровня 2.
     Быстрое увеличение значения счетчика Rx-No-Pkt-Buff и ошибок ввода
     Режим магистрального соединения между коммутатором и маршрутизатором
!—Дискуссионные форумы NetPro — избранные темы
—>Дополнительные сведения

Распространенные проблемы портов и интерфейсов

Состояние порта или интерфейса – Disable или Shutdown

Очевидная, но часто упускаемая из виду причина сбоя подключения к порту заключается в неправильной настройке коммутатора. Если индикатор порта горит постоянным оранжевым светом, это означает, что работа порта завершена программным обеспечением коммутатора, либо с помощью пользовательского интерфейса, либо внутренними процессами.

Примечание: Некоторые индикаторы портов данной платформы функционирует по отношению к протоколу STP отличным образом. Например, на коммутаторах серии Catalyst 1900/2820 индикаторы портов горят оранжевым светом, когда порты функционируют в режиме блокирования STP. В этом случае оранжевый свет может означать нормальную работу протокола STP. На коммутаторах серии Catalyst 6000/5000/4000 индикаторы портов не загораются оранжевым светом в случае блокирования портов протоколом STP.

Убедитесь, что порт или модуль не отключен или не выключен по каким-либо причинам. Если на одной стороне соединения работа порта или модуля завершена вручную, это соединение активируется только после повторного включения порта. Проверьте состояние порта на обеих сторонах.

В CatOS выполните команду show port и, если порт отключен, включите его.

Port  Name                 Status     Vlan       Duplex Speed Type
 ----- -------------------- ---------- ---------- ------ ----- ------------
  3/1                       disabled   1            auto  auto 10/100BaseTX
   !--- Use the set port enable mod/port command to re-enable this port.

Используйте команду show module , чтобы определить, отключен ли данный модуль. Если модуль отключен, включите его.

Mod Slot Ports Module-Type               Model               Sub Status
 --- ---- ----- ------------------------- ------------------- --- --------
 2   2    2     1000BaseX Supervisor      WS-X6K-SUP1A-2GE    yes ok
 16  2    1     Multilayer Switch Feature WS-F6K-MSFC         no  ok
 3   3    48    10/100BaseTX Ethernet     WS-X6348-RJ-45      no  disable
 				!--- Use the set module enable mod/port command to re-enable this port.

Для Cisco IOS используйте команду show run interface и проверьте, не находится ли данный интерфейс в состоянии завершения работы:

Switch#sh run interface fastEthernet 4/2
! interface FastEthernet4/2
  switchport trunk encapsulation dot1q
  switchport mode trunk
  shutdown
  duplex full
  speed 100
 end
 !--- Use the no shut command in config-if mode to re-enable this interface.

Если порт переходит в режим завершения работы сразу после перезагрузки коммутатора, вероятная причина заключается в настройке безопасности порта. Если в данном порту включена односторонняя лавинная маршрутизация, это может вызывать завершение работы порта после перезагрузки. На практике компании осуществляющее абонетское техническое облуживание компьютеров и сетевого оборудования отключают одностороннюю лавинную маршрутизацию. Корпорация Cisco рекомендует отключать одностороннюю лавинную маршрутизацию, так как это также гарантирует, что в таком порте не возникнет лавинная маршрутизация после достижения ограничения MAC-адресов.

Порт или интерфейс в состоянии «errDisable»

По умолчанию программное обеспечение, установленное на коммутаторе, может завершить работу порта или интерфейса при обнаружении определенных ошибок.

В выходных данных команды show port для CatOS может указываться состояние errdisable:

switch>(enable) sh port 4/3
    Port  Name                 Status     Vlan       Duplex Speed Type
   ----- -------------------- ---------- ---------- ------ ----- ------------ 
  4/3                        errdisable 150          auto  auto 10/100BaseTX
   !--- The show port command displays a status of errdisable.

Можно также воспользоваться командой show interface card-type {slot/port} status для Cisco IOS:

Router#show int fasteth 2/4 status
      Port    Name               Status       Vlan       Duplex  Speed Type
   Gi2/4                      err-disabled 1            full   1000 1000BaseSX
   !--- The show interfaces card-type {slot/port} status command for Cisco IOS
   !--- displays a status of errdisabled.
   !--- The show interfaces status errdisabled command shows all the interfaces
   !--- in this status.

Команда show logging buffer для CatOS и команда show logging для Cisco IOS также отображают сообщения об ошибках (точный формат сообщений различен), связанные с состоянием «errdisable».

Порты или интерфейсы, работа которых завершается из-за состояния ошибки, в CatOS и в Cisco IOS считаются причинами. Причины этого различны: от неправильной настройки EtherChannel, которая вызывает PAgP-переброску, до несоответствия дуплексных режимов, одновременной настройки режима PortFast и защиты порта от блоков BPDU, функции обнаружения односторонной связи (UDLD) и т.д.

Необходимо вручную включить порт или интерфейс, чтобы вывести его из состояния «errdisable», если не настроено восстановление из состояния «errdisable». В программном обеспечении CatOS версии 5.4(1) и выше поддерживается автоматическое повторное включение порта после его пребывания в состоянии отключения после ошибки в истечение настраиваемого периода времени. Cisco IOS в большинстве коммутаторов также обладают этой функциональной возможностью. Нижняя строка имеет этот вид, даже если настроить интерфейс на восстановление из состояния. Данная проблема продолжает возникать, пока не будет устранена ее основная причина.

Дополнительные сведения о причинах состояния «errdisable» для коммутаторов и восстановлении из него см. в документе Восстановление при состоянии порта «errDisable» на платформах CatOS.

Примечание: Используйте эту ссылку в качестве справки по состоянию «errdisable» на коммутаторах с Cisco IOS, так как основные причины одинаковы, вне зависимости от используемой операционной системы.

В этой таблице сравниваются команды, используемые для настройки проверки и устранения состояния «errdisable» на коммутаторах с CatOS и Cisco IOS. Выберите команду для перехода к документации по командам.

Команды CatOS для работы с состоянием «errdisable»

Действие

Команды Cisco IOS для работы с состоянием «errdisable»

set errdisable-timeout {enable | disable} {reason}

установка или настройка

errdisable detect cause

errdisable recovery cause

set errdisable-timeout interval {interval

установка или настройка

errdisable recovery {interval

show errdisable-timeout

проверка и устранение неполадок

show errdisable detect

show interfaces status err-disabled

Порт или интерфейс в неактивном состоянии

Одна из распространенных причин отсутствия активности портов на коммутаторах с CatOS — исчезновение сети VLAN, которой они принадлежат. Такая же проблема может возникнуть на коммутаторах с Cisco IOS, когда интерфейсы настроены в качестве портов коммутатора уровня 2 с помощью команды switchport .

Каждый порт коммутатора уровня 2 принадлежит сети VLAN. Каждый порт коммутатора уровня 3, настроенный в качестве коммутационного порта L2, также должен принадлежать некоторой сети VLAN. При удалении такой сети VLAN соответствующий порт или интерфейс становятся неактивным.

Примечание: Когда это происходит, на некоторых коммутаторах индикатор горит постоянным оранжевым светом на каждом порте.

В CatOS используйте команду show port или show port status вместе с командой show vlan для проверки:

Switch> (enable) sh port status 2/2
 Port Name Status Vlan Duplex Speed Type
 ----- -------------------- ---------- ---------- ------ ----- ------------
 2/2 inactive 2 full 1000 1000BaseSX
 !--- Port 2/2 is inactive for VLAN 2.
       Switch> (enable) sh vlan
  VLAN Name Status IfIndex Mod/Ports, Vlans
---- -------------------------------- --------- ------- ------------------------
 1 default active 5 2/1 
!--- VLANs are displayed in order and VLAN 2 is missing.

Для Cisco IOS используйте команду show interfaces card-type {slot/port} switchport вместе с командой show vlan , чтобы проверить.

Router#sh interfaces fastEthernet 4/47 switchport
   Name: Fa4/47Switchport: Enabled
   Administrative Mode: static access
   Operational Mode: static access
   Administrative Trunking Encapsulation: negotiate
   Operational Trunking Encapsulation: native
   Negotiation of Trunking: Off
   Access Mode VLAN: 11 ((Inactive))
   !--- FastEth 4/47 is inactive.
    Router#sh vlan    VLAN Name                             Status    Ports
  ---- -------------------------------- --------- -------------------------------
  1    default                          active    Gi1/1, Gi2/1, Fa6/6
  10   UplinkToGSR's                    active    Gi1/2, Gi2/2
   !--- VLANs are displayed in order and VLAN 11 is missing.
  30   SDTsw-1ToSDTsw-2Link             active	Fa6/45

Если коммутатор, удаливший сеть VLAN, является VTP-сервером для VTP-домена, у всех коммутаторов серверов и клиентов этого домена данная сеть VLAN также удаляется из их таблицы сетей VLAN. Когда данная сеть VLAN снова добавляется в таблицу сетей VLAN коммутатора VTP-сервера, порты коммутаторов домена, принадлежащие восстановленной сети VLAN, снова становятся активными. Порт помнит, какой сети VLAN он назначен, даже если эта сеть VLAN удалена. 

Увеличение значения счетчика отложенных кадров в интерфейсе коммутаторов Catalyst

Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного коммутатора. Обычно отложенные кадры — это кадры, которые были переданы успешно после ожидания носителя, так как он был занят. Они обычно наблюдаются в полудуплексных средах, в которых несущая уже используется, при попытке передачи кадра. Однако в дуплексных средах эта проблема возникает, когда к коммутатору направляется чрезмерная нагрузка.

Ниже описывается обходное решение.

  • Чтобы избежать ошибок согласования, жестко задайте использование дуплексного режима на обеих сторонах соединения.

  • Замените кабель и шнур коммутационной панели, чтобы гарантировать исправность кабеля и соединительных шнуров.

Перемежающиеся сбои при выполнении функции set timer [значение] from vlan [№ vlan]

Данная проблема возникает, когда логической схеме распознавания закодированных адресов (Encoded Address Recognition Logic, EARL) не удается задать требуемое число секунд для времени устаревания CAM сети VLAN. В данном случае время устаревания сети VLAN уже настроено на быстрое устаревание.

Когда сеть VLAN уже находится в процессе быстрого устаревания, схема EARL не может ее настроить на быстрое устаревание, процесс настройки таймера устаревания блокирован. По умолчанию время устаревания CAM равно пяти минутам, т.е. каждые 5 минут коммутатор очищает таблицу полученных MAC-адресов. Это гарантирует, что в таблице MAC-адресов (таблица CAM) содержатся только самые последние записи.

При быстром устаревании время устаревания CAM временно становится равным числу секунд, заданному пользователем, и используется в процессе создания уведомлений об изменении топологии (TCN). Идея заключается в том, что при изменении топологии это значение необходимо для ускорения очистки таблицы CAM, чтобы компенсировать изменение топологии.

Выполните команду show cam aging , чтобы проверить время устаревания CAM на данном коммутаторе. Процессы TCN и быстрого устаревания выполняются достаточно редко. Поэтому данное сообщение имеет уровень важности 3. Если сети VLAN часто участвуют в процессе быстрого устаревания, проверьте причину этого.

Наиболее распространенная причина уведомлений об изменении топологии — клиентские ПК, напрямую подключенные к коммутатору. При включении или отключении питания ПК порт коммутатора изменяет состояние, а коммутатор начинает процесс уведомления об изменении топологии. Это вызвано тем, что коммутатору неизвестно, что подключенное устройство является ПК. Коммутатору известно лишь то, что порт изменил состояние.

Чтобы разрешить данную проблему, корпорация Cisco разработала функцию PortFast для портов узлов. Преимущество PortFast заключается в том, что данная функция подавляет уведомление об изменении топологии для порта хоста. При проведени IT-аудита рекомендуется обозначать порты на которых включена функция PortFast.

Примечание: Кроме того, поскольку функция PortFast игнорирует вычисление топологии STP для порта, она может применяться только для портов хостов.

Чтобы включить PortFast для порта, выполните одну из следующих команд:

set spantree portfast mod/port enable | disable

или

set port host mod/port Корпорация Cisco рекомендует использовать эту команду, если на коммутаторе используется CatOS5.4 или более высокой версии.

Несоответствие режима магистрального соединения

Проверьте режим магистрального соединения на каждой стороне связи. Убедитесь, что на обеих сторонах используется либо один и тот же режим магистрального соединения (ISL или IEEE 802.1Q), либо на обеих сторонах режим магистрального соединения отключен. Если включить режим магистрального соединения («on» вместо «auto» или «desirable») на одном порте, а на другом его отключить (off), порты не смогут обмениваться данными. Режим магистрального соединения изменяет форматирование пакета. Порты должны согласовать формат, используемый для данного соединения, иначе они не поймут друг друга.

В CatOS используйте команду show trunk {mod/port}, чтобы проверить статус магистрали и убедиться в совпадении параметров собственной сети VLAN (для dot1q) на обеих сторонах.

Switch> (enable) sh trunk 3/1
    * - indicates vtp domain mismatch
   Port      Mode         Encapsulation  Status        Native vlan
   --------  -----------  -------------  ------------  -----------
    3/1      desirable    dot1q          trunking      1      Port      Vlans allowed on trunk
   --------  ---------------------------------------------------------------------
    3/1      1-1005,1025-4094
 !--- Output truncated.

Для Cisco IOS используйте команду show interfaces card-type {mod/port} trunk , чтобы проверить конфигурацию режима магистрального соединения и собственную сеть VLAN.

Router#sh interfaces fastEthernet 6/1 trunk
      Port      Mode         Encapsulation  Status        Native vlan   Fa6/1     desirable    802.1q
         trunking      1      Port      Vlans allowed on trunk   Fa6/1     1-4094
 !--- Output truncated.

Рекомендации, ограничения, а также дополнительные сведения о различных режимах магистрального соединения см. в следующих документах:

  • Системные требования для реализации режима магистрального соединения

  • Страница поддержки технологии магистрального соединения

Кадры jumbo, giant и baby giant

По умолчанию максимальный размер передаваемого блока данных (MTU) для кадра Ethernet равен 1500 байтам. Если в передаваемом трафике MTU превышает поддерживаемое значение MTU, коммутатор не пересылает такой пакет. Кроме того, в зависимости от аппаратного и программного обеспечения на некоторых платформах в результате увеличиваются значения счетчиков ошибок портов и интерфейсов.

  • Jumbo-кадры не определены в стандарте IEEE Ethernet и зависят от поставщика. Их можно определить как кадры размера, превышающего размер стандартного кадра Ethernet (1518 байтов, включая заголовок L2 и контрольную сумму CRC). Размер jumbo-кадров обычно значительно больше (более 9000 байтов).

  • Кадры giant определяются как кадры с неверным значением последовательности FCS, размер которых превышает размер максимального кадра Ethernet (1518 байтов).

  • Кадры baby giant — это кадры, лишь незначительно превышающие максимальный размер кадра Ethernet. Обычно это кадры размером до 1600 байтов.

Поддержка jumbo-кадров и кадров baby giant на коммутаторах Catalyst зависит от платформы и даже от модулей внутри коммутатора. Поддержка jumbo-кадров также зависит от версии программного обеспечения.

Дополнительные сведения о требованиях к системе, настройке, поиску и устранению проблем, связанных с jumbo-кадрами и кадрами baby giant см. в документе Настройка поддержки кадров jumbo/giant на коммутаторах Catalyst .

Не удается проверить связь с конечным устройством

Проверьте связь с конечным устройством, сначала отправляя эхо-запросы из напрямую подключенного коммутатора, затем последовательно проверяйте каждый порт, интерфейс и магистраль, пока не будет найден источник проблемы подключения. Убедитесь, что каждому коммутатору доступен MAC-адрес конечного устройства в таблице CAM.

В CatOS используйте команду show cam dynamic {mod/port}.

Switch> (enable) 
sh cam dynamic 3/1 * = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
 X = Port Security Entry $ = Dot1x Security Entry    
VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type]
 ----  ------------------    -----  -------------------------------------------
 2     00-40-ca-14-0a-b1             3/1 [ALL] 
!--- A workstation on VLAN 2 with MAC address 00-40-ca-14-0a-b1 is seen in the CAM table 
!--- on the trunk port of a switch running CatOS. Total Matching CAM Entries Displayed  =1 Console> (enable)

Для Cisco IOS используйте команду show mac address-table dynamic или подставьте ключевое слово interface.

Router# sh mac-address-table int fas 6/3
 Codes: * - primary entry      vlan   mac address     type    learn qos            ports
 ------+----------------+--------+-----+---+-------------------------- *
    2  0040.ca14.0ab1   dynamic  No    --  Fa6/3
  !--- A workstation on VLAN 2 with MAC address 0040.ca14.0ab1 is directly connected
 !--- to interface fastEthernet 6/3 on a switch running Cisco IOS.

Если известно, что в таблице CAM коммутатора действительно содержится MAC-адрес устройства, определите, принадлежит ли данное устройство сети VLAN, которой принадлежит узел, где предпринимается попытка установления связи.

Если конечное устройство относится к другой сети VLAN, необходимо настроить коммутатор L3 или маршрутизатор, чтобы разрешить связь между устройствами. Убедитесь в правильной настройке адресации L3 на конечном устройстве и в маршрутизаторе или коммутаторе L3. Проверьте IP-адрес, маску подсети, основной шлюз, конфигурацию протокола динамической маршрутизации, статические маршруты и т.д.

Использование команды Set Port Host или Switchport Host для устранения задержек во время запуска

Если станциям не удается связаться со своими основными серверами при подключении через коммутатор, то проблема может быть связана с задержками в порту коммутатора, который становится активным после включения соединения на физическом уровне. В некоторых случаях задержки могут достигать 50 секунд.

Некоторые рабочие станции просто не могут ждать так долго во время поиска своих серверов. Такие задержки вызываются протоколом STP, согласованиями режима магистрального соединения (DTP) и согласованиями EtherChannel (PAgP). Все эти протоколы можно отключить для портов доступа, где они не нужны. В результате порт или интерфейс коммутатора начинает пересылать пакеты всего через несколько секунд после установления соединения с соседним устройством.

Команда set port host введена в CatOS версии 5.4. Эта команда отключает режим канала и режим магистрального соединения и переводит порт в STP-состояние пересылки.

Switch> (enable) set port host 3/5-10 Port(s) 3/5-10 channel mode set to off.
!--- The set port host command also automatically turns off etherchannel on the ports. 				
Warning: Spantree port fast start should only be enabled on ports connected to a single host.
Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops.
Use with caution.
!--- Notice the switch warns you to only enable port host on access ports.
Spantree ports 3/5-10 fast start enabled.
Dot1q tunnel feature disabled on port(s) 3/5-10. Port(s) 3/5-10 trunk mode set to off. 				
!--- The set port host command also automatically turns off trunking on the ports.

Примечание: В CatOS версий, предшествующих версии 5.4, использовалась команда set spantree portfast {mod/port} enable . В текущих версиях CatOS сохраняется возможность использования только этой команды, однако для этого необходимо по отдельности отключить режим магистрального соединения и EtherChannel, чтобы максимально снизить время задержек при запуске рабочих станций. Ниже перечислены необходимые дополнительные команды: set port channel {mod/port} off и set trunk {mod/port} off.

Для Cisco IOS можно использовать команду switchport host , чтобы отключить объединение портов в канал и включить функцию PortFast протокола STP, и команду switchport nonegotiate , чтобы отключить пакеты согласования DTP. Используйте команду interface-range , чтобы сделать это одновременно на нескольких интерфейсах.

Router6k-1(config)#int range fastEthernet 6/13 - 18 
Router6k-1(config-if-range)#switchport 
Router6k-1(config-if-range)#switchport host
switchport mode will be set to access spanning-tree portfast will be enabled channel group will be disabled 
!--- Etherchannel is disabled and portfast is enabled on interfaces 6/13 - 6/18. 
Router6k-1(config-if-range)#switchport nonegotiate  				
!--- Trunking negotiation is disabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#end Router6k-1#

В Cisco IOS есть возможность использования команды global spanning-tree portfast default для автоматического применения функции PortFast к любому интерфейсу, настроенному в качестве коммутационного порта доступа уровня 2. Описание возможностей этой команды см. в Справочнике по командам для используемого выпуска программного обеспечения. Можно также воспользоваться командой spanning-tree portfast для каждого интерфейса, однако для этого необходимо по отдельности отключить режим магистрального соединения и EtherChannel, чтобы максимально снизить время задержек при запуске рабочих станций.

Дополнительные сведения об устранении задержек во время запуска см. в документе Использование режима PortFast и других команд для устранения задержек соединения во время запуска рабочей станции.

Проблемы со скоростью/дуплексным режимом, автоматическим согласованием или сетевой платой

В случае большого количества ошибок выравнивания, ошибок FCS или поздних конфликтов это может указывать на одно из следующего:

  • несоответствие дуплексных режимов

  • неисправный или поврежденный кабель

  • неполадки сетевой платы

Несоответствие дуплексных режимов

Распространенная проблема со скоростью/дуплексным режимом — несоответствие параметров дуплексных режимом между двумя коммутаторами, между коммутатором и маршрутизатором, либо между коммутатором и рабочей станцией или сервером. Такая ситуация может возникать, если параметры скорости и дуплексных режимов запрограммированы жестко вручную, или в случае проблем автоматического согласования между двумя устройствами.

Если такое несоответствие возникает между двумя устройствами Cisco с включенным протоколом CDP, в консоли или буфере регистрации обоих устройств отображаются CDP-сообщения об ошибках. Протокол CDP полезен при обнаружении ошибок, а также для сбора статистики о портах и системах соседних устройств Cisco. Протокол CDP разработан корпорацией Cisco. Он работает путем отправки пакетов хорошо известному MAC-адресу 01-00-0C-CC-CC-CC.

В рассмотренном ниже примере показаны сообщения журнала, которые появляются в результате несоответствия дуплексных режимов между двумя коммутаторами серии Catalyst 6000: на одном используется CatOS, а на другом — Cisco IOS. В таких сообщениях обычно сообщается суть несоответствия и место его возникновения.

2003 Jun 02 11:16:02 %CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected on port 3/2 
!--- CatOS switch sees duplex mismatch.
 Jun  2 11:16:45 %CDP-4-DUPLEX_MISMATCH:
 duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex).
  !--- Cisco IOS switch sees duplex mismatch.

В CatOS используйте команду show cdp neighbor [mod/port] detail для отображения данных протокола CDP о соседних устройствах Cisco.

Switch> (enable) sh cdp neighbor 3/1 detail Port (Our Port):
 3/1 Device-ID: Router Device Addresses:   IP Address: 10.1.1.2 Holdtime: 133 sec
 Capabilities: ROUTER SWITCH IGMP
 Version:   Cisco Internetwork Operating System Software   IOS (tm) c6sup2_rp Software (c6sup2_rp-PK2S-M),
 Version 12.1(13)E6, EARLY DEPL OYMENT RELEASE SOFTWARE (fc1)
   TAC Support: http://www.cisco.com/tac   Copyright (c) 1986-2003 by cisco Systems, Inc.
   Compiled Fri 18-Apr-03 15:35 by hqluong Platform: cisco Catalyst 6000
 Port-ID (Port on Neighbors's Device): FastEthernet6/1 				
!--- Neighbor device to port 3/1 is a Cisco Catalyst 6000 Switch on 
!--- FastEth 6/1 running Cisco IOS. VTP Management Domain: test1Native VLAN: 1 Duplex: full
!--- Duplex is full.
 System Name: unknown
 System Object ID: unknown
 Management Addresses: unknown
 Physical Location: unknown Switch> (enable)

Для Cisco IOS используйте команду show cdp neighbors card-type {slot/port} detail для отображения данных протокола CDP о соседних устройствах Cisco.

Router#sh cdp neighbors fastEthernet 6/1 detail
 -------------------------
 Device ID: TBA04251336 Entry address(es):
   IP address: 10.1.1.1 Platform: WS-C6006,
  Capabilities: Trans-Bridge Switch IGMP Interface:
 FastEthernet6/1,  Port ID (outgoing port): 3/1
 Holdtime : 152 sec  Version : WS-C6006 Software,
 Version McpSW: 6.3(3) NmpSW: 6.3(3) Copyright (c) 1995-2001 by Cisco Systems 
!--- Neighbor device to FastEth 6/1 is a Cisco Catalyst 6000 Switch
 !--- on port 3/1 running CatOS.
 advertisement version: 2 VTP Management Domain: 'test1' Native VLAN:
 1 Duplex: full 				
!--- Duplex is full.  Router#

Установка значения «auto» для параметров скорости/дуплексного режима на одной стороне и значения «100/Full-duplex» на другой также является неправильной конфигурацией и может привести к несоответствию дуплексных режимов. Если в порту коммутатора возникает много поздних конфликтов, это обычно указывает на проблему несоответствия дуплексных режимов и может привести к переводу порта в состояние отключения из-за ошибки. Сторона с полудуплексным режимом ожидает пакеты только в определенные промежутки времени, не постоянно, поэтому получение пакета в несоответствующее время воспринимается как конфликт. Существуют и другие причины поздних конфликтов, кроме несоответствия дуплексных режимов, но это одна из самых распространенных причин. Всегда на обеих сторонах соединения настраивайте автоматическое согласование скорости/дуплексного режима или задавайте эти параметры на обеих сторонах вручную.

В CatOS используйте команду show port status [mod/port] для отображения настроек скорости и дуплексного режима и другой информации. Используйте команду set port speed и set port duplex для жесткой настройки обеих сторон на значения 10 или 100 и «half» или «full», при необходимости.

Switch> (enable) sh port status 3/1 Port  Name                 Status     Vlan       Duplex Speed Type
 ----- -------------------- ---------- ---------- ------ ----- ------------
  3/1                       connected  1          a-full a-100 10/100BaseTX Switch> (enable)

Для Cisco IOS используйте команду show interfaces card-type {slot/port} status для отображения параметров скорости и дуплексного режима, а также другой информации. Используйте команду скорость и duplex в режиме конфигурации интерфейса для жесткой настройки обеих сторон на значения 10 или 100 и «half» или «full», при необходимости.

Неисправный или поврежденный кабель

Всегда проверяйте кабель на наличие заметного повреждения или сбоя. Кабель может быть достаточно хорошим для соединений на физическом уровне, и в тоже время повреждать пакеты в результате скрытого повреждения проводов или разъемов. Проверьте или замените медный или оптоволоконный кабель. Замените конвертер GBIC (если можно) для оптоволоконных соединений. Исключите все неправильные подключения к коммутационной панели и медиаконвертеры между источником и назначением. Попробуйте вставить кабель в другой порт или интерфейс (если есть) и проверить, сохранится ли данная проблема.

Проблемы автоматического согласования и сетевых плат

Иногда возникают проблемы между коммутаторами Cisco и определенными сетевыми платами сторонних производителей. По умолчанию порты и интерфейсы коммутаторов Catalyst настроены на автоматическое согласование. Такие устройства, как портативные компьютеры или другие устройства, также обычно настраиваются на автоматическое согласование, тем не менее иногда возникают проблемы с автоматическим согласованием.

Для устранения проблем с автоматическим согласованием часто рекомендуется жестко запрограммировать обе стороны. Если ни автоматическое согласование, ни жесткое программирование не работает, возможно, возникла неполадка в микропрограмме или программном обеспечении сетевой платы. Для разрешения проблемы обновите драйвер сетевой платы до последней версии, доступной на веб-узле производителя.

Подробные сведения о разрешении проблем с параметрами скорости/дуплексного режима и автоматическим согласованием см. в документе Настройка и устранение неполадок автоматического согласования Ethernet 10/100/1000 MB в полудуплексном и дуплексном режимах.

Петли в дереве STP

Петли протокола STP могут вызвать серьезные проблемы с производительностью, маскирующиеся под неполадки портов или интерфейсов. В такой ситуации, пропускная способность снова и снова используется одними и теми же кадрами, оставляя очень мало ресурсов законному трафику.

В данном документе рассматриваются причины возможных сбоев протокола STP, информация, которую необходимо найти для идентификации источника проблемы, и типы проектов, минимизирующие риски STP.

Петли также могут вызываться однонаправленными соединениями. Дополнительные сведения о проблемах, связанных с однонаправленными соединениями, см. в разделе «UDLD: одностороннее соединение» настоящего документа.

UDLD: одностороннее соединение

Однонаправленное соединение — это соединение, при котором трафик передается только в одном направлении, а в обратном направлении трафик отсутствует. Коммутатору не известно, что соединение для обратного трафика не функционирует (соединение воспринимается портом как активное и работоспособное).

Вышедший из строя оптоволоконный кабель или другие проблемы, связанные с кабелем/портом, могут стать причиной превращения соединения в одностороннее. Эти частично работающие соединения могут вызывать такие проблемы, как петли STP, если задействованные коммутаторы не осведомлены о частичной неисправности соединения. Функция обнаружения однонаправленной связи (UDLD) может перевести порт в состояние «errdisable» при обнаружении однонаправленного соединения. Команду «udld aggressive-mode» можно использовать на коммутаторах с CatOS и Cisco IOS (сведения о поддерживаемых командах см. в заметках о выпуске) для соединений «точка-точка» между коммутаторами, в которых неправильно функционирующие соединения не допускаются. Эта функция может помочь при идентификации трудно обнаруживаемых проблем, связанных с возникновением однонаправленной связи.

Сведения о настройке функции обнаружения однонаправленной связи (UDLD) см. в документе Общие сведения и настройка протокола обнаружения однонаправленной связи (UDLD).

Отложенные кадры (Out-Lost или Out-Discard)

Большое количество отложенных или «Out-Discard» кадров (на некоторых платформах они также называются Out-Lost) означает, что выходные буферы коммутатора полностью заполнены и коммутатор был вынужден отбрасывать данные пакеты. Причиной этого может быть то, что данный сегмент функционирует при недостаточных параметрах скорости и/или дуплексного режима, либо что через порт проходит слишком большой объем трафика.

Сбои буфера вывода могут вызываться следующими причинами:

Неоптимальная скорость/дуплексный режим для заданного объема трафика

Сеть может пересылать через порт слишком много пакетов, чтобы порт мог их обработать при текущих параметрах скорости/дуплексного режима. Это может произойти на участках, где осуществляется передача от нескольких высокоскоростных портов к одному (обычно более медленному) порту. Устройство, вызвавшее зависание порта, можно подключить к более быстрому носителю. Например, если порт работает на скорости 10 Мбит/с, подключите данное устройство к порту 100 Мбит/с или к порту Gigabit. Можно изменить топологию, чтобы поменять маршрутизацию кадров.

Проблемы перегруженности: сегмент слишком занят

Если является общим, другие устройства в данном сегменте могут передавать так много данных, что у коммутатора нет возможности для передачи. По возможности избегайте каскадного подключения концентраторов. Перегруженность может привести к потере пакетов. Потеря пакетов вызывает повторные передачи на транспортном уровне, что в свою очередь приводит к возникновению задержки на уровне приложений. По возможности замените соединения с пропускной способностью 10 Мбит/с на линии 100 Мбит/с или Gigabit Ethernet. Некоторые устройства можно перенести из перегруженных в менее загруженные сегменты. Задача устранения перегруженности сети должна быть приоритетной.

Приложения

Порой характеристики передачи трафика используемых приложений могут привести к проблемам с выходными буферами. Передачи файлов NFS от подключенного к плате Gigabit сервера, использующего протокол UDP с размером окна 32K, представляют пример настройки приложения, которые приводят к данному типу проблемы. Если все другие советы и инструкции (проверка скорости/дуплексного режима, проверка наличия физических ошибок соединения, допустимости всего трафика и т.д.), предлагаемые в данном документе, не помогли устранить данную проблему, уменьшите размер отправляемых приложением блоков. Это поможет смягчить негативное влияние неполадки.

Неполадки программного обеспечения

Если наблюдаемое поведение системы/сети можно охарактеризовать только как «странное», определите конкретный узел, являющийся источником неполадок. Проведите все предложенные до сих пор проверки. Если это не помогает устранить возникшие неполадки, возможно, наличие проблем программного или аппаратного обеспечения. Обычно проще обновить программное обеспечение, чем оборудование. Сначала обновите программное обеспечение.

В CatOS используйте команду show version , чтобы проверить версию текущего программного обеспечения и освободить флеш-память для обновления.

Для Cisco IOS используйте команду show version , чтобы проверить версию текущего программного обеспечения, вместе с командой dir flash: или dir bootflash: (в зависимости от платформы), чтобы проверить доступную флеш-память для обновления

Обновление программного обеспечения

Чтобы получить информацию об обновлении ПО для коммутаторов Catalyst, выберите необходимую платформу в списке коммутаторов для ЛВС (LAN Switches) или коммутаторов ATM (ATM Switches), а затем перейдите к разделам «Configuration» (Настройка) > Software Upgrade (Обновление ПО) и Working With Configuration Files (Работа с файлами конфигурации).

Несовместимость аппаратного и программного обеспечения

Возможна ситуация, когда программное обеспечение несовместимо с оборудованием. Такое случается, когда поступает новое оборудование, требующее специальной поддержки от программного обеспечения. Для получения дополнительных сведений о совместимости программного обеспечения используйте средство Software Advisor.

Ошибки в программном обеспечении

В операционной системе могут быть ошибки. После загрузки более новой версии программного обеспечения нередко проблема устраняется. С помощью средства поиска ошибок в ПО можно искать информацию об известных ошибках в программном обеспечении.

Поврежденные образы

Образ может быть поврежден или утрачен. Чтобы получить информацию о восстановлении поврежденных образов ПО, выберите необходимую платформу в списке коммутаторов для ЛВС (LAN Switches) или коммутаторов ATM (ATM Switches), а затем перейдите к разделам «Troubleshooting» (Устранение неполадок) > «Recovery from Corrupted or Missing Software» (Восстановление поврежденного или отсутствующего образа ПО).

Ошибки оборудования

Проверьте результаты выполнения команды show module для коммутаторов серии Catalyst 6000 и 4000 с ПО CatOS или Cisco IOS.

Switch> (enable) sh mod Mod Slot Ports Module-Type               Model               Sub Statu
 --- ---- ----- ------------------------- ------------------- ----------- 1   1    2
     1000BaseX Supervisor      WS-X6K-S2U-MSFC2    yes ok 15  1    1
     Multilayer Switch Feature WS-F6K-MSFC2        no  ok 3   3    8
     1000BaseX Ethernet        WS-X6408A-GBIC      no  faulty 5   5    48
     10/100BaseTX Ethernet     WS-X6348-RJ-45      no  faulty 				
!--- Status of "faulty" indicates a possible hardware problem. 
!--- This could be a line card problem, but since two mods are effected, 
!--- perhaps there's a problem with the supervisor. 
!--- Use the reset command (CatOS) or hw-module{mod}reset command (Cisco IOS), 
!--- or try physically reseating the modules and the supervisor. 
!--- Also, try moving the supervisor to slot 2.

Проверьте результаты выполнения процедуры POST на коммутаторе, чтобы проверить появление указаний на сбои портов коммутатора. В случае сбоя теста модуля или порта в результатах тестирования отображается буква «F».

В CatOS используйте команду show test , чтобы просмотреть результаты всех тестов. Чтобы просмотреть результаты тестов для каждого модуля, используйте команду show test {mod} команда:

Switch> (enable) sh test 3 Diagnostic mode: complete   (mode at next reset: minimal) 
!--- The diaglevel is set to complete which is a longer but more thorough test. 
!--- The command to do this for CatOS is set test diaglevel complete. 
Module 3 : 16-port 1000BaseX EthernetLine 
Card Status for Module 3 : PASS Port Status :  
Ports 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
-----------------------------------------------------       
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
GBIC Status :  
Ports 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16  
-----------------------------------------------------        
.  .  .  .  .  N  .  .  .  .  .  .  .  .  N  N 
Line Card Diag Status for Module 3  (. = Pass, F = Fail, N = N/A) 
Loopback Status [Reported by Module 1] :  
Ports 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16  
-----------------------------------------------------       
 F  F  F  F  F  F  F  F  F  F  F  F  F  F  F  F  				
!--- The failed loopback tests mean the ports are currently unusable. 
!--- Use the reset {mod} command or, if necessary, physically reseat the 
!--- module to try and fix this problem. 
!--- If these steps fail, open a case with Cisco Technical Support.

Для Cisco IOS на модульных коммутаторах, таких как Cat6000 и 4000, используйте команду show diagnostics. Чтобы просмотреть результаты процедуры POST для каждого модуля, используйте команду show diagnostics module {mod} команда.

ecsj-6506-d2#sh diagnostic module 3   Current Online Diagnostic Level = Minimal 				  
!--- The diagnostic level is set to minimal which is a shorter,  
!--- but also less thorough test result.   
!--- You may wish to configure diagnostic level complete to get more test results.    
Online Diagnostic Result for Module 3 : MINOR ERROR   
Online Diagnostic Level when Line Card came up = Minimal   Test Results: (. = Pass, F = Fail, U = Unknown)   
1 . TestLoopback :   
Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24  
 ----------------------------------------------------------------------------        
 .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  F  F  F  F F  F   
!--- Notice the MINOR ERROR test result and failed loopback test which means   
!--- these ports are currently unusable.   
!--- Use the hw-module{mod}reset command or, if necessary, physically reseat the  
!--- module to try and fix this problem.     
!--- If these steps fail, open a case with Cisco Technical Support.

Примечание: Для коммутаторов серии Catalyst 3750, 3550, 2970 , 2950/2955 и 2900/3500XL используйте команду show post , которая сообщает о прохождении или сбое проверки состояния оборудования. Индикаторы на этих портах помогают понять результаты процедуры POST. См. документ Общие сведения о результатах процедуры Post.

Чтобы получить дополнительную информацию об устранении аппаратных проблем на коммутаторах Catalyst с CatOS и Cisco IOS, перейдите на страницы поддержки ATM-коммутаторов и коммутаторов для ЛВС, выберите необходимую платформу и перейдите к разделам Troubleshooting (Устранение неполадок) > Hardware (Оборудование).

Уведомления об обнаруженных проблемах см. в разделе Field Notices (Уведомления о дефектах) для ATM-коммутаторов и коммутаторов для ЛВС.

Ошибки ввода в интерфейсе уровня 3, подключенном к коммутационному порту уровня 2.

По умолчанию все порты уровня 2 находятся в режиме dynamic desirable (динамическое согласование), поэтому такой порт пытается сформировать магистральный канал и отправляет DTP-пакеты удаленному устройству. Когда интерфейс уровня 3 подключен к порту коммутатора уровня 2, он не может интерпретировать эти кадры, что приводит к ошибкам ввода, ошибкам WrongEncap и потерям очереди ввода.

Чтобы устранить данную проблему, измените режим порта коммутатора на static access (статический доступ) или trunk (магистраль) в соответствии с требованиями.

Switch2(config)#int fa1/0/12 Switch2(config-if)#switchport mode access

или

Switch2(config)#int fa1/0/12 Switch2(config-if)#switchport trunk encapsulation dot1q
         				        Switch2(config-if)#switchport mode trunk

Быстрое увеличение значения счетчика Rx-No-Pkt-Buff и ошибок ввода

Значение счетчика Rx-No-Pkt-Buff для портов может возрастать, если есть blade-серверы, такие как WS-X4448-GB-RJ45, WS-X4548-GB-RJ45 и WS-X4548-GB-RJ45V. Кроме того, некоторый рост отбрасывания пакетов является обычным результатом пульсирующего трафика.

Число ошибок этих типов быстро растет, особенно если через данное соединение проходит интенсивный трафик или если к данному интерфейсу подключены такие устройства, как серверы. Такой трафик высокой интенсивности перегружает выделенные ресурсы портов, что вызывает исчерпание входных буферов и быстрый рост значения счетчика Rx-No-Pkt-Buff и ошибок ввода.

Такие типы ошибок в данном интерфейсе связаны с проблемой трафика на перегруженных портах. В модулях коммутации WS-X4448-GB-RJ45, WS-X4548-GB-RJ45 и WS-X4548-GB-RJ45V есть 48 перегруженных портов в шести группах по восемь портов в каждой:

  • Порты 1, 2, 3, 4, 5, 6, 7, 8

  • Порты 9, 10, 11, 12, 13, 14, 15, 16

  • Порты 17, 18, 19, 20, 21, 22, 23, 24

  • Порты 25, 26, 27, 28, 29, 30, 31, 32

  • Порты 33, 34, 35, 36, 37, 38, 39, 40

  • Порты 41, 42, 43, 44, 45, 46, 47, 48

Восемь портов в каждой группе используют общую схему, что эффективно уплотняет группу в одно неблокируемое дуплексное подключение Gigabit Ethernet к внутренней фабрике коммутаторов. Для каждой группы из восьми портов принимаемые кадры помещаются в буфер и отправляются через общее соединение Gigabit Ethernet на внутреннюю фабрику коммутаторов. Если объем принимаемых портом данных начинает превышать возможности буфера, управление потоком отправляет удаленному порту кадр паузы, чтобы временно остановить передачу трафика и предотвратить потерю кадров.

Если количество кадров, принимаемых любой группой портов, превышает пропускную способность в 1 Гбит/с, данное устройство начинает отбрасывать кадры. Такое отбрасывание не очевидно, так как кадры отбрасываются во внутренней микросхеме ASIC, а не в реальных интерфейсах. Это может привести к уменьшению скорости передачи пакетов через данное устройство.

Если есть устройства, которые должны поддерживать передачу большого объема трафика через данный интерфейс, рассмотрите возможность такого использования одного порта в каждой группе, чтобы общая схема, используемая в одной группе, не была затронута этим трафиком. Когда модуль коммутации Gigabit Ethernet используется не полностью, соединения портов можно распределить между группами портов для максимального использования пропускной способности. Например, в случае модуля коммутации WS-X4448-GB-RJ45 10/100/1000 можно подключить порты из различных групп, например, порты 4, 12, 20 или 30 (в любом порядке), перед подключением портов из той же группы, таких как 1, 2, 3, 4, 5, 6, 7 и 8.

Если это не решает проблему, необходимо рассмотреть возможность использования модуля без перегруженных портов. Если проблему не получается решить самостоятельно, то рекомендуется обратиться в компанию осуществляющую аутсорсинговое сопровождение вашего бизнеса.

Режим магистрального соединения между коммутатором и маршрутизатором

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

Для разрешения этой проблемы выполните следующие действия.

  1. Убедитесь, что коммутатором и маршрутизатором используется протокол CDP и они могут связаться друг с другом.

  2. Отключите запросы keepalive в интерфейсе маршрутизатора.

  3. Заново настройте инкапсуляцию магистрали на обоих устройствах.

Когда запросы keepalive отключены, протокол CDP позволяет соединению работать в нормальном режиме.

Еще десять лет тому назад локальные сети были относительно простыми: они строились на основе хабов, мостов и маршрутизаторов, и каждое сетевое устройство можно было легко отличить от других. Устранение неисправностей также не представляло трудностей: если пользователь был подключен к хабу, применялись правила диагностики в домене коллизий, а в той точке, где домен коллизий подключается к мосту, все ошибки заканчивались. Диагностика с помощью анализатора протоколов была вполне эффективна, поскольку большинство сетевых администраторов знали основы сети и используемых протоколов. Затем в сетях появились коммутаторы. Проблемы, связанные с коммутируемой средой, в целом аналогичны сложностям при работе с разделяемыми ресурсами: трудно понять, какой именно сбой произошел, что послужило источником проблемы и насколько это повлияло на работу смежных компонентов. В коммутируемых сетях ответы на эти вопросы должны относиться к конкретному порту.

Вот типичные вопросы, которые возникают при использовании коммутируемой среды:

  • Насколько загружен каждый порт?
  • Как найти источник ошибок?
  • Что является источником широковещательного шторма (размножения некорректно сформированных широковещательных сообщений)?
  • Правильно ли работают таблицы MAC-адресов?
  • Какие станции подключены к данному порту?
  • Ограничивает ли коммутатор скорость работы какого-либо протокола или порта?
  • Находится ли данный порт в виртуальной локальной сети (VLAN)? Если да, то находится ли сервер в этой же самой VLAN?

Общие рекомендации по конфигурации сети

Проблемы обнаружения неисправностей начинаются с того, что коммутатор выполняет функции моста 2-го уровня, и усложняются необходимостью поддержки VLAN, а также других функций и правил коммутации 3го и более высоких уровней сетевой модели OSI. Поиск ошибок в работе функций, использующих информацию 4-го уровня (например, распределение нагрузки), требует отличного знания настроек коммутатора.

При установке коммутатора отдельный домен коллизий создается на каждом полудуплексном порту — такова природа коммутатора. Если к порту коммутатора подключен хаб, домен коллизий может вырасти до размера, максимально допустимого для данной реализации Ethernet. Тем не менее благодаря снижению стоимости коммутаторов большинство новых сетей имеют лишь по одной станции на порт.

Сам коммутатор становится частью единого широковещательного домена, включающего в себя другие коммутаторы. Если в сети используются функции 3-го уровня, то создается множество широковещательных доменов, равное количеству сетей VLAN. В предельном случае (если позволяют параметры коммутатора) каждый порт может быть сконфигурирован как отдельный широковещательный домен, и это очень ограничивает возможности для диагностики. Кроме того, при такой конфигурации в коммутаторе должна поддерживаться функция маршрутизации, обычно требующая значительных ресурсов центрального процессора коммутатора для управления трафиком. Трудно предположить, что маршрутизация в сети каждого отдельного запроса и ответа может оказаться целесообразной, поэтому подобной конфигурации следует избегать. К сожалению, она встречается очень часто (хотя и в менее очевидном варианте) в тех сетях, где все серверы относятся к одной подсети или широковещательному домену, а все пользователи находятся в нескольких других подсетях или доменах. На практике при такой конфигурации сети все запросы все равно должны быть маршрутизированы.

Если работы по обслуживанию сети должны ограничиваться только одной серверной комнатой, рекомендуется размещать серверы в различных сетях VLAN. Такая конфигурация позволит коммутационной матрице работать в качестве моста 2-го уровня для обычного трафика, а маршрутизации будут подлежать только необычные или редкие запросы. Если сервер обслуживает не одну, а несколько групп пользователей, следует установить дополнительные сетевые адаптеры в сервере, чтобы сохранить связь с пользователями на 2-м уровне.

Пять методов диагностики коммутируемых сетей

Существует пять основных методов, позволяющих определить, что происходит в коммутаторе. Каждый метод предполагает собственный подход и имеет как положительные, так и отрицательные стороны. Как и во множестве других ситуаций, связанных с сетями, здесь нет единственно правильного ответа. Наиболее подходящее решение определяется, с одной стороны, наличием нужного инструментария, а с другой — возможностью прерывания связи при использовании данного метода диагностики.

Даже если скомбинировать все возможные методы, они не смогут обеспечить такой же уровень контроля коммутируемой сети, как в случае применения в сети хабов. Весь трафик, идущий через коммутатор, просмотреть почти невозможно. В большинстве случаев при поиске неисправности предполагается, что трафик проходит между компьютером и сервером или через линию связи с другим узлом (Uplink). Если две рабочие станции обмениваются информацией напрямую, трафик не будет проходить через Uplink, как впрочем, и через любой другой порт коммутатора. И если специально не проверить трафик между этими двумя компьютерами, то можно и не обнаружить проблему.

connect01.gif
Рис. 1. Простейший вариант сети с коммутатором

Для простоты рассмотрим одну из типичных конфигураций сети — сервер, подключенный к коммутатору (рис. 1). Пользователь (пользователи), у которого возникают проблемы, может быть подключен к тому же коммутатору или получать доступ к серверу через Uplink — линию связи, ведущую к другому коммутатору или маршрутизатору. При этом жалоба пользователя будет звучать примерно так: «Связь с сервером слишком медленная». Такая формулировка, к сожалению, не говорит сетевому администратору почти ничего.

Метод 1. Настройка коммутатора через Telnet или последовательный порт

В процессе поиска неисправности сетевой администратор (если у него есть пароль доступа) может проверить правильность настроек коммутатора путем подключения к консольному порту RS-232 (рис. 2) или с помощью Telnet-сессии.

connect02.gif
Рис. 2. Использование консольного порта

Однако полученные в результате данные о конфигурации коммутатора сами по себе малоинформативны. Чтобы понять, корректны они или нет, придется использовать один или несколько других методов поиска неисправностей.

Некоторые коммутаторы снабжены дополнительными средствами диагностики, однако диапазон их возможностей различен в зависимости от производителя и модели коммутатора. В любом случае, чтобы воспользоваться этими инструментами, требуются немалый опыт и глубокие теоретические знания.

Метод 2. Подключение анализатора к свободному порту коммутатора

Самый простой метод обнаружения неполадок — подключение прибора с функцией мониторинга (например, анализатора протоколов) к любому неиспользуемому порту на коммутаторе (рис. 3).

connect03.gif
Рис. 3. Мониторинг с любого свободного порта

Подключенный таким образом прибор получает доступ в широковещательный домен как обычная рабочая станция,не нарушая работы других пользователей. К сожалению, коммутатор (который мы считаем многопортовым мостом) будет направлять на контролируемый порт лишь незначительную часть трафика. Это нормальное поведение моста, поскольку его назначение — предотвращать попадание трафика в те порты, которым он не предназначен. А анализатор протоколов в этом случае не запрашивал никакого трафика и, скорее всего, не передавал ни одного фрейма (рис. 4). Прибор «увидит» лишь несколько фреймов в минуту вместо нескольких тысяч в секунду, которые могут передаваться между станциями и сервером.

Трафик, приходящий на порт мониторинга, будет почти полностью состоять из широковещательных фреймов. Возможно, там окажется еще несколько случайных фреймов, пришедших от неизвестных отправителей. Такие фреймы могут появляться из-за старения таблицы MAC. Некоторые невнимательные сетевые администраторы в таких случаях решают, что в сети действительно почти 100% пакетов — широковещательные, и при этом не замечают, что уровень использования (утилизации) сетевых ресурсов очень низкий. В результате делается некорректный вывод о наличии в сети широковещательного шторма. А если жалоб от пользователей не поступало, то администратор вообще может решить, что такая ситуация — часть нормального процесса функционирования сети.

Поскольку описанный подход к диагностике сети практически бесполезен, прибор должен сам запрашивать трафик. «Опрос» широковещательного домена полезен для обследования сети и поиска других проблем, однако он не поможет продвинуться в решении проблемы медленного соединения, о которой сообщил пользователь.

Более содержательные результаты могут быть получены при использовании так называемого зеркального копирования (зеркалирования) портов: большинство коммутаторов разрешают копировать трафик из выбранного порта или портов на другой порт, к которому и подключается анализатор (рис. 5). Зеркалирование позволяет прибору «видеть» трафик между сервером и «проблемным» компьютером, пользователь которого жалуется на низкую производительность. У старых моделей коммутаторов в качестве порта для мониторинга можно сконфигурировать специально выделенный порт; на новых коммутаторах для этого подходит любой порт.

Способ реализации данного метода варьируется у различных производителей, но имеется несколько общепринятых способов зеркалирования. Отметим, что в большинстве случаев пакеты, перенаправленные в порт мониторинга, будут отфильтрованы так же, как и пакеты, посылаемые на все остальные порты. Это означает, что все ошибки будут отфильтрованы коммутатором и не достигнут порта мониторинга. Тогда зеркалирование трафика на порт мониторинга может оказаться неэффективным для целей диагностики, поскольку при таком подходе коммутатор скрывает целый класс проблем. Кроме того, чтобы правильно настроить порт мониторинга, нужно подключиться к нему либо с консоли (порт RS-232 на коммутаторе), либо через Telnet-сессию — следовательно, помимо анализатора потребуется еще и компьютер.

«Зеркальный» порт мониторинга часто бывает только принимающим, хотя некоторые производители коммутаторов делают его двунаправленным. На него может поступать копия трафика от любого другого порта — одного или нескольких. И чем больше портов в коммутаторе «прослушивает» порт мониторинга, тем выше вероятность того, что ему не хватит пропускной способности и тестирующее устройства получит не все фреймы.

Пропускная способность порта мониторинга — серьезная проблема. Дело в том, что порт имеет приемную (Rx) и передающую (Tx) части. Передающая часть порта мониторинга может быть заблокирована коммутатором, но независимо от этого пропускная способность приемного канала (от порта коммутатора к анализатору) все равно ограничена. Если зеркалируется полнодуплексный порт, работающий с той же скоростью, что и порт мониторинга, коммутатор может просто отбросить часть трафика, не выдав об этом никакого сообщения. И неважно, подключен прибор по полуили полнодуплексному каналу — ограничение скорости работы приемника все равно будет одним и тем же.

Предположим, возникла необходимость проанализировать трафик сервера, подключенного к коммутатору на скорости 100 Мбит/с по полнодуплексному каналу (рис. 6). При полном дуплексе приемная и передающая части могут соответственно передавать и принимать по 100 Мбит/с трафика каждая. Таким образом, суммарная пропускная способность канала составляет 200 Мбит/с. Для зеркалирования трафика, идущего от сервера, может использоваться только приемник (Rx). Следовательно, размер контролируемого трафика ограничен максимумом в 100 Мбит/с. Любой трафик сервера, превышающий 50% емкости данной линии (200 Мбит/с), будет потерян.

connect06.gif
Рис. 6. Ограничение пропускной способности порта мониторинга

Если на порт мониторинга поступает трафик с нескольких портов, проблема соответственно усложняется. Впрочем, поскольку большинство коммутаторов работает далеко не на 100% своей пропускной способности, данная проблема может и не коснуться вашей сети, но потенциально она существует. Для большинства пользователей сети загруженность соединений не превышает 10%, и изредка происходит кратковременный, но большой по амплитуде всплеск трафика.

Очевидное решение проблемы — подключить прибор к высокоскоростному порту, который может принять весь «зеркальный» трафик. Если бы пропускная способность порта мониторинга (см. рис. 6) составляла 1 Гбит/с вместо 100 Мбит/с, совокупный трафик в 200 Мбит/с был бы с легкостью принят и проанализирован.

Метод 3. Установка хаба в тестируемый сегмент

Во многих сетях большую часть трафика создают совместно используемые ресурсы (например, файловые серверы). Если установить хаб между файлсервером и коммутатором и подключить к нему анализатор (рис. 7), то последний окажется в том же широковещательном домене, что и сервер. При такой схеме подключения анализатор «видит» весь входящий и исходящий трафик сервера, благодаря чему сетевой администратор может узнать о неудачных попытках подключения зарегистрированных пользователей к серверу, а также определить, не приводит ли низкая производительность канала к сбросу соединений.

connect07.gif
Рис. 7. Использование хаба для мониторинга канала подключения сервера

Такой метод, к сожалению, неприменим в сетях с несколькими серверами. Размещать хаб рядом с каждым сервером нецелесообразно, а если переносить хаб от сервера к серверу, то придется останавливать сеть на время, требуемое для подключения хаба. Конечно, установить хаб — дело нескольких минут, но текущие соединения при этом будут сброшены. Кроме того, нет гарантии, что анализатор сможет работать на скорости канала, по которому подключен сервер.

Тем не менее использование хаба полезно для решения ряда задач мониторинга трафика и поиска ошибок. В частности, это почти единственный способ разобраться в ошибках MAC-уровня в коммутируемой среде. Конечно, такие ошибки можно отследить и с помощью SNMP-клиента, но для полноценного анализа ошибок значительно лучше «увидеть» их напрямую на тестирующем устройстве.

У данного метода есть два существенных недостатка. Во-первых, серверная линия связи не может быть полнодуплексной, в противном случае несоответствие режимов передачи приведет к большему количеству ошибок, чем сможет обнаружит администратор. Во-вторых, для реализации этого метода необходим хаб, а большинство современных хабов на самом деле являются мостами, «замаскированными» под хаб. Установить такое устройство, не являющееся настоящим хабом с разделяемой пропускной способностью, — все равно что установить еще один коммутатор, и в результате увидеть искомый трафик будет невозможно.

Двухскоростные хабы 10/100 на самом деле представляют собой два хаба — на 10 и 100 Мбит/c, соединенных между собой мостом. Такой хаб использовать можно, только следует убедиться, что сервер и анализатор работают на однойскорости.

Также встречаются дешевые коммутаторы, у которых от настоящих хабов осталось только название и низкая цена. Производители стремятся унифицировать производство, и им выгоднее снизить цены на коммутаторы, чем сохранять производство хабов. Такие «хабы» для описанного выше метода совершенно непригодны.

Метод 4. Использование разветвителя кабеля

Этот метод аналогичен предыдущему с установкой хаба, за исключением того, что анализатор сможет только принимать, но не передавать данные (рис. 8). Существуют разветвители для медных и для волоконно-оптических кабелей.

connect08.gif
Рис. 8. Использование разветвителя

Оптические разветвители (сплиттеры) являются пассивными устройствами и не требуют электропитания. Сплиттер характеризуется процентом отводимой оптической мощности (например, разветвитель 80:20 отводит 20% мощности). Очевидно, что добавление сплиттера в линию связи приводит к уменьшению мощности сигнала, поступающего на приемник. А если бюджет по затуханию на этой линии практически исчерпан, то добавление сплиттера неизбежно приведет к нарушению связи. Впрочем, некоторые оптические передатчики более устойчивы к внесению затухания, так что можно попробовать установить сплиттер на другой стороне линии.

Медные разветвители также вносят в линию дополнительное затухание и приводят к потере связи, если линия уже работает на пределе своих возможностей. Медным разветвителям требуется электропитание, так как они принимают, восстанавливают и передают полученный сигнал. Впрочем, при пропадании питания сама линия все равно будет работать — отключится только порт мониторинга (конечно, при условии, что разветвитель установлен правильно).

Удобство использования разветвителей заключается в том, что они невидимы для остального сетевого оборудования. Достаточно установить разветвитель один раз на контролируемом соединении и использовать его при необходимости. К сожалению, для его установки придется резать кабель. Надо сказать, что это не единственный недостаток. Разветвитель работает отдельно с каждым направлением передачи, следовательно, порт мониторинга состоит из двух физических соединений (рис. 9).

connect09.gif
Рис. 9. Функциональная схема работы

разветвителя

Поэтому для одновременного мониторинга обоих направлений в тестирующем приборе должно быть два входа. Обычно приборы с двумя входами могут объединять оба потока и анализировать их одновременно. Можно, конечно, анализировать каждое направление по отдельности, но это значительно сложнее. Эффективность данного метода одинакова для полу- или полнодуплексных соединений.

Метод 5. Сбор данных по протоколу SNMP

Самый эффективный метод диагностики коммутируемой сети — запросить информацию о ситуации в сети у самого коммутатора. Это делается удаленно с помощью протокола SNMP (рис. 10) или путем непосредственного подключения к консольному порту коммутатора. Использование SNMP удобнее, поскольку администратору не нужно ходить с ноутбуком от коммутатора к коммутатору — вся информация будет поступать на его рабочее место. Если реализована система управления сетью, можно настроить коммутатор на автоматическую отправку сообщений о событиях, проходящих в сети (SNMP trap), например, об ошибке или выходе значения какого-либо параметра за пределы заданных пороговых значений. Сетевому администратору останется лишь с помощью тестирующего устройства выяснить, почему это нежелательное событие произошло.

connect10.gif
Рис. 10. Использование протокола SNMP для мониторинга коммутатора

Буквально все коммутаторы (кроме самых дешевых) оснащены функцией SNMP-управления. Разница лишь в том, насколько детализирована информация, предоставляемая коммутатором. Некоторые коммутаторы имеют средства SNMP, предлагающие только информацию об устройстве в целом, другие (более дорогие) предоставляют подробную информацию по каждому порту в отдельности.

SNMP, пожалуй, самый удобный и наименее разрушительный метод мониторинга коммутируемой сети. SNMPклиент может располагаться в любом месте сети, а доступ к диагностической информации защищен паролем (community string). К одному и тому же коммутатору может быть несколько паролей с различными правами доступа. Ограничения доступа также могут касаться подсетей и даже отдельных IPадресов. В отношении защищенного доступа к коммутатору необходимо обратить внимание на следующее. Большинство коммутаторов поставляется с паролем «public», и просто поразительно, как много сетевых администраторов не меняют его! Еще одна угроза безопасности связана с тем, что пароли передаются по сети в открытом виде. Шифрование предусмотрено в версии SNMPv3, но она пока не получила широкого распространения.

Перечень контролируемых параметров зависит от используемой базы MIB. Большинство производителей коммутаторов предлагают MIB-базы собственной разработки, но можно воспользоваться и стандартной (MIB II, Ethernet-Like Interface MIB, RMON Ethernet, RMON 2, SMON и т.д.).

Маршрутизаторы, через которые проходят SNMP-пакеты, могут накладывать на них различные ограничения, а межсетевые экраны (firewall) могут полностью блокировать SNMP. Кроме того, SNMP-агенты могут работать с ошибками, что приводит к ложным срабатываниям. Тем не менее SNMP в целом является очень полезным средством диагностики.

Заключение

В реальной жизни чаще всего используется такой метод диагностики — дождаться жалоб от пользователей. И не следует его отбрасывать из-за слишком очевидной простоты — на самом деле он очень эффективен. Сообщество пользователей имеет обостренное чутье на то, как должна вести себя сеть. Любое отклонение от нормального хода вещей будет доведено до сведения службы технической поддержки. После жалобы пользователя сетевой администратор может начать процесс диагностики с соответствующего порта подключения. Однако такой подход можно сравнить с тушением пожара, а ведь всем известно, что пожары лучше предотвращать, чтобы потом не пришлось их тушить. Для предотвращения проблем следует организовать регулярный мониторинг — собирать информацию с каждого коммутатора и отслеживать загруженность каждого порта, и это избавит службу технической поддержки от большинства жалоб пользователей.

Источник

Устранение ошибок в сети

В
сетях возникают проблемы. Даже если в
сети осуществляется мониторинг,
обо­рудование надежно, а пользователи
аккуратны, иногда возникают ситуации,
когда в сети происходят сбои. Характерным
качеством хорошего сетевого администратора
является способность находить причины
сбоев в сети, анализировать возникающие
проблемы и устранять их в напряженной
обстановке, когда сетевой сбой вызывает
простой в работе компании. В настоящем
разделе содержится обзор методов
устра­нения ошибок и предлагаются
другие средства локализации возникающих
в сети проблем. В этот обзор включены
ранее описанные методы, а также некоторые
до­полнительные средства. Как уже
говорилось ранее, эти методы могут быть
лучшими способами решения возникающих
в сети проблем.

Первым
и самым важным средством решения проблем
является ведение инженер­ного журнала.
Запись в него всей относящейся к сети
информации может определить прямой
путь к диагностике проблемы. Заметки
в этом журнале могут сказать, какие
меры уже предпринимались и какое
воздействие они оказали на состояние
сети. Эта информация может оказаться
исключительной ценной для того, чтобы
не повторять бесполезных действий.
Заметки в инженерном журнале могут
также оказаться ценны­ми при передаче
решения проблемы другому сотруднику
с тем, чтобы он не делал за­ново всю
работу. Копия этих заметок должна быть
также включена в решение пробле­мы
когда составляется отчет о проделанной
работе. Он может служить справочным
ма­териалом в случае возникновения
аналогичных проблем в будущем.

Другим
существенным элементом в процессе
устранения ошибок является нане­сение
меток. Метки следует делать на всем,
включая оба конца любого отрезка
гори­зонтального кабеля. На метке
должен быть указан не только номер
кабеля, но и ме­сто расположения
другого конца и характер использования
кабеля — для передачи данных, голоса
или видео. Такой тип метки при устранении
неисправностей может оказаться даже
более ценным, чем схема расположения
кабелей, поскольку эта ин­формация
находится там же, где и сам элемент
сети, а не где-то в ящике стола. Вме­сте
с метками кабелей, следует сделать
метки для каждого порта концентратора,
коммутатора или маршрутизатора, на
которых должно быть указано расположение,
назначение и точка подсоединения. Это
значительно облегчает решение
возникаю­щих проблем. В заключение
отметим, что метки с описанием места
расположения и назначения должны быть
и у всех других компонентов, подсоединенных
к сети. При таком подходе к нанесению
меток можно легко определить место
расположения всех компонентов сети и
их назначение. Правильно выполненное
нанесение меток, ис­пользуемое вместе
с сетевой документацией, созданной при
установке сети и ее мо­дернизации,
дает полную картину сети и имеющиеся
в ней связи. Важно отметить, что
документация полезна только в том
случае, если она соответствует текущему
со­стоянию сети. Все внесенные в сеть
изменения должны быть отражены на
метках соответствующих устройств и в
документации по устройству или кабелю,
в которых они произошли. Это дает полную
картину состояния сети.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

Одной из тем, которые встретится на экзамене CCNA будет «Диагностика и устранение неполадок в работе коммутаторов 2-го уровня».
 Для того, чтобы не запутаться на экзамене нужно запомнить одно простое
правило, и пользоваться простым планом действий. Основное правило при
диагностике и устранении неполадок — это «Не трогай технику, и она тебя
не подведет». Т.е. «Зачем лез, если оно само работало?»… Не совсем так,
конечно. Это основное правило системного администрирования в целом.
Почему-то вспомнилось…

Основное правило — «Не делать предположение о том,
что находится в рабочем состоянии, а что нет, предварительно этого не
проверив». Т.е. нельзя предполагать, что порт коммутатора активен, и
находится в рабочем состоянии, не проверив этого. Все остальное — по
плану.

1. Диагностика физического уровня и порта коммутатора

·        Кабель: тип, категория, длинна

·        Состояние порта

·        Согласованность портов ( full-duplex / half-duplex )

·        Принадлежность порта корректному VTP VLAN

2. Диагностика и устранение неполадок VLAN и VTP-trunk-ов

·        Согласованность номера native VLAN на всех узлах VTP домена.

·        Согласованность режимов локального и удаленного VTP trunk-ов ( Dynamic Auto / Dynamic Desirable)

·        Принадлежность каждого VLAN уникальной IP сети

·        Параметры конфигурации для Inter-VLAN маршрутизации

3. Диагностика и устранение неполадок VTP

·        Наличие необходимых параметров конфигурации VLAN в running-config

·        Согласованность параметров VTP на всех коммутаторах

·        Появление проблем после добавления нового коммутатора

·        Отключение порта(ов) после включения питания коммутатора

4. Диагностика и устранение неполадок STP

·        Root-бридж по схеме сети

·        Петли коммутации

·        Лог изменения конфигурации STP

·        Процесс выбора root-бриджа

1. Диагностика физического уровня и порта коммутатора
 

Первое что нужно сделать для выяснения возможных причин сбоев или полной
неработоспособности сети — это проверить кабель. Не думаю, что в рамках
экзаменационных вопросов встретится что-то кроме вопросов о
правильности выбора типа используемого кабеля для различного
оборудования. Речь идет о crossover ( перекрестный обжим ) straightthrough ( прямой обжим ) кабелях. Применения типа обжима в документации Cisco предлагается запомнить по простому принципу:

·    прямой ( straightthrough ) применяется для подключения оборудования разного типа; 
·    перекрестный ( crossover ) — для подключения оборудования одного типа.

Разделить оборудование на типы можно по его положению относительно Ethernet сегмента — маршрутизаторы, клиентские станции и сервера являются конечными системами в сегменте сети Ethernet,
в то время как повторители, хабы и свитчи являются основой его
инфраструктуры. Из этого простого разделения и нужно исходить при выборе
типа кабеля.

Далее необходимо проверить состояние портов на обеих сторонах неисправного соединения. Основная задач выяснить нет ли портов “disable” или “errDisable” ( в зависимости от причины вызвавшей отключение порта ).

Проверить состояние порта можно по выводу команды show для соответствующего интерфейса / порта

FastEthernet0/2 is up, line protocol is up (connected)

  Hardware is Fast Ethernet, address is 0017.596d.2a02 (bia 0017.596d.2a02)

  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

          reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

——————————-пропущено—————————————-

На следующем этапе необходимо проверить согласованность режимов портов. В документации Cisco
рекомендуется отключать автоопределение портов, и устанавливать
«вручную» необходимый режим. Такая практика позволяет избежать возможных
ошибок автоматического определения режима работы порта коммутатора. В
тоже время, она же может привести к ошибке конфигурирования. Выяснить
согласованность режимов работы портов можно из вывода команды show interface для портов на обеих сторонах неработающего канала.

Switch#show interfaces f0/2

FastEthernet0/2 is up, line protocol is up (connected)

  Hardware is Lance, address is 000c.856c.0a01 (bia 000c.856c.0a01)

 BW 100000 Kbit, DLY 1000 usec,

          reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 100Mb/s

——————————-пропущено—————————————-

В случае, если порт находится в режиме access, и ему назначен номер несуществующего / или случайно удаленного VLAN, вывод команды show interface будет бесполезен для выяснения причины неработоспособности порта. В таком случае необходимую информацию может предоставить show interface interface switchport 

SwitchX# show interfaces fa0/2 switchport

Name: Fa0/2

Switchport: Enabled

Administrative Mode: static access

Operational Mode: static access

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: native

Negotiation of Trunking: Off

Access Mode VLAN: 5 (Inactive)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: None

——————————-пропущено—————————————-

На некоторых коммутаторах Cisco на таких портах индикатор светится немигающим оранжевым.

2. Диагностика и устранение неполадок VLAN и VTP-trunk-ов

Для нормального функционирования IEEE 802.1Q trunk-ов они должны быть сконфигурированы с одинаковым значением параметра native VLAN. Для того чтобы проверить это необходимо просмотреть вывод команды show interfaces interface switchport или show intrface trunk на коммутаторах, находящихся на обеих сторонах неработающего соединения.

SwitchX#show interface f0/1 switchport

Name: Fa0/1

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

——————————-пропущено—————————————-

SwitchX#show interface trunk

Port        Mode         Encapsulation          Status        Native vlan

Fa0/1       on                  802.1q                trunking               1

——————————-пропущено—————————————-

Не знаю, какова вероятность именно такой неисправности в экзаменационной
лабораторной работе или вопросе, так как при нормальных обстоятельствах
коммутаторы должны “жаловаться” прямо в консоль о том, что значение native VLAN не согласовано.

Native VLAN mismatch discovered on FastEthernet0/1 (1), with Switch FastEthernet0/1 (99)

Для того чтобы установить одинаковое значение native VLAN на обоих коммутаторах, необходимо в режиме Interface Configuration Mode выполнить команду

SwitchX(config-if)#switchport trunk native vlan VLAN number

Кроме этого, к неисправности в работе trunk-ов может привести несогласованность параметра Administrative Mode. Это обусловлено тем, что в некоторых случаях возможен перевод порта в режим trunk автоматически, используя протокол DTP. Всю необходимую информацию можно узнать из вывода команды show interfaces interface switchport.

SwitchX#show interface f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
——————————-пропущено—————————————-

SwitchY#show interface f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
——————————-пропущено—————————————-

Различия между Dynamic Auto и Dynamic Desirable заключается в том, что в первом случае будет создано trunk — соединение в ответ на DTP – запрос, а во втором случае будет инициироваться попытка создания trunk – соединение и посылаться DTP – запрос. Если оба порта будут настроены Dynamic Auto, trunk — соединение не будет создано.

Чтобы установить желаемое значение параметра Administrative Mode, необходимо в режиме Interface Configuration Mode выполнить команду

SwitchX(config-if)#switchport mode MODE

Несмотря на то, что технологии, реализованные Cisco Systems,
позволяют оборудованию в некоторых случаях производить
автоконфигурирование, в официальной документации все параметры
рекомендуется устанавливать самостоятельно. В данном случае, параметр Administrative Mode не является исключением, и ему должно быть присвоено значение trunk для портов, которые должны создавать trunk-соединение.

Для нормального взаимодействия между узлами в пределах одного VLAN необходимо чтобы эти узлы находились в одной IP-сети. И на оборот, если узлы разнесены в различные VLAN
– в различных IP-сетях. В случае, если эти простые условия не будут
соблюдены, бесполезно ожидать сетевого взаимодействия между этими двумя
узлами. Для того, чтобы это проверить нет необходимости выполнения каких
либо команд на коммутаторах, достаточно просто сопоставить значения VLAN и присвоенных узлам IP-адресов, полученных из вывода команды ipconfig.

В случае возникновения неисправностей interVLAN
взаимодействия, возможной причиной может быть неправильная конфигурация
оборудования, вовлеченного в него. Это в первую очередь касается
конечных узлов, на которых может быть неправильно сконфигурирован шлюз
по умолчанию. Проверить правильность настроек интерфейса на конечно
станции можно командой ipconfig

Следующей причиной подобных проблем может являться неправильная конфигурация роутера, обеспечивающего interVLAN – маршрутизацию. Для выяснения возможных неисправностей необходимо четко представлять нормальных алгоритм работы InterVLAN — маршрутизации. Основной причиной возникновения неисправностей interVLAN
взаимодействия может являть неправильная конфигурация одного или
нескольких дополнительных интерфейсов на маршрутиазторе. Это может быть,
как неправильно настроенные параметры инкапсуляции IEEE 802.1Q,
так и неправильное присвоение адреса. Для того, чтобы получить
необходимую информацию можно просмотреть текущую конфигурацию
маршрутизатора командой

show running-config

——————————-пропущено—————————————-
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
!
interface FastEthernet0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0
!
interface FastEthernet0/0.40
 encapsulation dot1Q 40
 ip address 192.168.40.1 255.255.255.0
!
——————————-пропущено—————————————-

или просмотрев вывод команды

show interface sub-if name

Router#show interfaces FastEthernet 0/0.20
FastEthernet0/0.20 is up, line protocol is up (connected)
  Hardware is PQUICC_FEC, address is 0030.f2e1.c301 (bia 0030.f2e1.c301)
  Internet address is 192.168.20.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID 20
  ARP type: ARPA, ARP Timeout 04:00:00,
Last clearing of «show interface» counters never

Номер дополнительного интерфейса не обязательно должен соответствовать номеру VLAN ( такое соответствие упрощает понимание конфигурации и дальнейшее администрирование ), в то время как параметр Vlan ID – обязательно должен соответствовать номеру VLAN.
Кроме того, адрес, присвоенный дополнительному интерфейсу, должен быть
согласован с планом адресации в пределах обслуживаемого VLAN, а также быть эквивалентным адресу основного шлюза для этого VLAN.

3. Диагностика и устранение неполадок VTP

Интересным явлением, с точки зрения возможности появления  в
экзаменационном вопросе со статусом неисправности, является различие в
способе сохранения информации протокола VTP и базы данных VLAN на коммутаторах с различными режимами протокола VTP. Такая нелогичность не может быть пропущена авторами экзамена.

Коммутаторы в VTP — режиме  Server и Client хранят всю информацию протокола VTP ( включая базу VLAN ) в файле vlan.dat. В то время, как коммутаторы в режиме Transparent — в файле конфигурации. Это различие может быть причиной неожиданных последствий выполнения команд

Более комплексной проблемой является отсутствие обмена данными между коммутаторами в пределах одного VTP домена. Для этого существует достаточно большое количество объективных причин..

Так как информация распространяется только через trunk-и, необходимо проверить являются ли порты, соединяющие коммутаторы, trunk-ами. Сделать это можно командой  

show interface trunk

SwitchX#show interface trunk

Port        Mode         Encapsulation          Status        Native vlan

Fa0/1       on                  802.1q                trunking               1

Fa0/2       on                  802.1q                trunking               1

Fa0/3       on                  802.1q                trunking               1

——————————-пропущено—————————————-

 Далее необходимо проверить параметры VTP домена domain и password. Оба параметра являются чувствительными к регистру. Если допустить ошибку в имени VTP домена или пароле, то обмен информацией не будет происходить.  Получить информацию о имени домена можно при помощи команды show vtp status

SwitchX#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
——————————-пропущено—————————————-

Для того, чтобы исключить возможное различие между настройками пароля на
коммутаторах, вовлеченных в проблему, необходимо временно сбросить VTP пароль. Для этого необходимо в Global Configuration Mode выполнить команду no vtp password.

Версии протокола VTP не являются совместимыми. Если в VTP – домене есть коммутаторы, не поддерживающие VTP V2,  то его (VTP V2) нельзя использовать. В случае если все коммутаторы поддерживают VTP V2,  достаточно активировать эту версию протокола на коммутаторе, который является сервером для данного VTP домена, и все остальные коммутаторы автоматически перейдут на эту версию. По умолчанию используется  VTP V1.

Коммутаторы, использующие версию протокола VTP V1 и находящиеся в режиме Transparent, распространяют информацию только по VTP домену, к которому они принадлежат. Обновления, имеющие отношение к другим VTP доменам уничтожаются. В случае, если подобный коммутатор использует версию протокола VTP V2, то обновления имеющие отношение к другим VTP доменам передаются.  Посмотреть какая версия протокола VTP используется можно при помощи команды show vtp status.

SwitchX#show vtp status
VTP Version :2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
——————————-пропущено—————————————-

Параметр VTP Version  указывает на возможность использования VTP V2.  Значение Disabled  для параметра VTP V2 Mode указывает на то, что коммутатор использует VTP V1

Номера VLAN из дополнительного диапазона (от 1025 до 4094 ) не распространяются автоматически. VLAN-ы с номерами из этого диапазона, должны настраиваться на каждом коммутаторе отдельно.

Обновления не вносят изменения в конфигурацию клиент в том случае, если Configuration Revision у клиента выше, чем в пришедшем от сервера обновлении. Посмотреть значение Configuration Revision   можно в выводе команды show vtp status.

SwitchX#show vtp status
VTP Version                                    : 2
Configuration Revision                 : 0
Maximum VLANs supported locally : 255
Number of existing VLANs              : 5
VTP Operating Mode                      : Server
VTP Domain Name                         : Cisco
——————————-пропущено—————————————-

Так как на коммутаторах Cisco по умолчанию значение VTP Operating Mode установлено Server,  и при некоторых обстоятельствах  Configuration Revision может быть выше чем у коммутатора используемого в качестве сервера для VTP домена, то в такой ситуации вновь добавленный коммутатор может изменить существующую базу VLAN. В случае, если его база VLAN будет пустой, то все VLAN
будут удалены. Следствием этого может быть ситуация, когда абсолютно
все порты  на коммутаторах, после включения питания, не активны (  как
было описано в п. 1 ), так как принадлежат не существующим VLAN. Для того, чтобы избежать подобной ситуации необходимо на вновь добавляемом коммутаторе обнулить значение  Configuration Revision переведя его сначала в режим Transparent, а потом в режим Server. Или сначала изменив значение  VTP Domain Name на любое другой, а потом вернув нужное значение. В обоих случаях  значение параметра Configuration Revision обнулится.

4. Диагностика и устранение неполадок STP

Диагностика и устранение неполадок протокола STP
возможна только в случае  нормального документирования топологии сети.
Это подразумевает наличие информации о том, какой коммутатор является Root,
какие каналы являются резервными и какие порты находятся в
заблокированном состоянии.   Только в этом случае возможна дальнейшая
диагностика.  Это необходимо для того, чтобы прежде чем  искать что
починить, иметь представление о том, как это все работало до того

Чтобы выявить несоответствия реального положения дел в сети и документации, достаточно использовать команду show spanning-tree. Из вывода данной команды можно определить какой коммутатор является в данный момент Root, в также текущее состояние портов относительно STP топологии.

Для быстрого восстановления работоспособности сети, разъединить петли
коммутации. Для этого нужно отключить те порты коммутаторов, которые их
образуют. И в этом случае документация STP
топологии будет незаменима. Так основанием для принятия решения какие
порты блокировать будет информация о том, какие порты были
заблокированы.

Определить Root-бридж согласно документации. Для того, чтобы не предоставлять возможность STP принимать решении о назначение корневого коммутатора для STP топологии, необходимо в Global Configuration Mode, для каждого из настроенных на коммутаторе  VLAN, выполнить команду

SwitchX (config)#spanning-tree vlan VLAN ID root primary.

В таком случае коммутатор автоматически выставит приоритет ниже, чем у существующего корневого коммутатора STP.

Время конвергенции ( схождения ) сети при использовании 802.1d и PVST+ составляет 30 -50 секунд. В случае использования RSTP и PVRST+ — не более 2-х секунд. При таком соотношении, использование режима pvst
неприемлемо. В случае если схождение сети происходит медленней, чем
ожидается, возможно, не все коммутаторы настроены на использование PVRST+. Какой режим используется в данный момент можно выяснить из первой строки вывода команды  show spanning-tree summary.

SwitchX#show spanning-tree summary
Switch is in pvst mode
——————————-пропущено—————————————-

Для того чтобы установить необходимый режим STP необходимо в Global Configuration Mode выполнить команду

SwitchX (config)#spanning-tree mode rapid-pvst

Данная тема (Диагностика и устранение неполадок в работе) является одной из самых сложных в рамках курса CCNA. Ее нельзя просто взять и выучить. Поэтому необходимо уделить особое внимание пунктам 3 и 4.

Источник

Я работал над квазирезонансным преобразователем энергии, который в предельно упрощенном виде выглядел так, как изображено на Рисунке 1.

Двухтактная пара мощных MOSFET должна была включаться и выключаться в обычной последовательности, и при включении каждого из транзисторов его ток сток-исток IDS должен был нарастать и снова спадать по синусоидальной кривой. Форма кривой была задана последовательным резонансом С1 с общей индуктивностью – суммой индуктивности L1, индуктивности рассеяния вторичной обмотки T1 и индуктивности рассеяния той половины первичной обмотки, которая работала в данном полупериоде.

Вебинар «Мощные модульные системы питания MEAN WELL 3+N. Новинки и хиты» (22.06.2023)

Это упрощенная конструкция квазирезонансного двухтактного инвертора.
Рисунок 1. Это упрощенная конструкция квазирезонансного двухтактного инвертора.

Эта форма сигнала определялась резонансом LC-контура, но попеременная коммутация полуобмоток, фактически, превращала процесс в квазирезонансный.

Если бы две половины первичной обмотки были в точности одинаковыми, их индуктивности рассеяния также были бы в точности одинаковыми, и тогда в точности одинаковыми были бы и формы токов I1 и I2, хотя и сдвинутыми на 180°. Если бы резонансы были именно такими, каждый MOSFET выключался бы ровно в тот самый момент, когда ток IDS этого MOSFET вернулся к нулю (Рисунок 2).

На этой диаграмме показано идеальное переключение в квазирезонансной схеме.
Рисунок 2. На этой диаграмме показано идеальное переключение
в квазирезонансной схеме.

Ложку дегтя в эту бочку меда добавило то, что две половины первичной обмотки были не совсем одинаковыми. Очень незначительное различие индуктивностей рассеяния, обусловленное естественными технологическими факторами, привело к коммутационным ошибкам, хорошо заметным на Рисунке 3.

Несогласованные индуктивности рассеяния вызывают ошибки переключения.
Рисунок 3. Несогласованные индуктивности рассеяния вызывают
ошибки переключения.

Если бы индуктивность рассеяния была больше номинальной, IDS еще не успел бы опуститься до нуля, когда MOSFET этого плеча уже выключился бы (ток I1 на Рисунке 3). С другой стороны, если бы индуктивность рассеяния была меньше номинальной, IDS не только достигал бы нуля, но и начинал бы течь в противоположном направлении до тех пор, пока не выключился MOSFET (ток I2 на Рисунке 3).

В нашем реальном устройстве мы могли бы немного отрегулировать задающую частоту, но приведение в «идеальное состояние» одной стороны схемы оставило бы другую сторону с существенной «коммутационной ошибкой». Идея попытаться достичь компромисса между двумя сторонами также была сочтена недостаточно хорошей.

Первоначальная емкость конденсатора C1 у нас составляла 0.068 мкФ, а расчетная частота LC-резонанса равнялась 100 кГц. Из стандартной формулы для частоты резонанса следовало, что сумма описанных индуктивностей, учитывающая, конечно же, соотношение витков Т1, составляла 37.25 мкГн, из которых большая часть приходилась на L1, но коммутационный дисбаланс и возникающие в результате ошибки мы сочли слишком серьезными.

Мы уменьшили емкость C1 с 0.068 мкФ до 0.022 мкФ, что потребовало увеличения индуктивности дросселя, которая стала равной 115.1 мкГн. Мы сделали дроссель L1 со значительно более высокой индуктивностью, и получили результаты, представленные на Рисунке 4.

С помощью настроек коммутационные ошибки можно уменьшить.
Рисунок 4. С помощью настроек коммутационные ошибки можно уменьшить.

Мы никогда не смогли бы полностью устранить коммутационные ошибки, поскольку две половины первичной обмотки T1 всегда немного несбалансированы. Однако мы смогли уменьшить эти ошибки до приемлемо малых значений.

Источник

Ускорьте свой ПК всего за несколько кликов

  • 1. Скачайте и установите ASR Pro
  • 2. Откройте приложение и нажмите кнопку «Сканировать».
  • 3. Выберите файлы или папки, которые вы хотите восстановить, и нажмите кнопку «Восстановить».

    • Загрузите это программное обеспечение сейчас и попрощайтесь с проблемами вашего компьютера. г.

    Вы можете столкнуться с ошибкой, отображающей устранение неполадок маршрутизации IP-протокола. Вообще есть разные пути решения этой главной проблемы, и мы о них прямо и поговорим.Процесс, используемый для передачи знаний об IP-коммуникациях, называется вашим интернет-протоколом (IP), который определяет точный маршрут и место назначения каждого пакета компьютерных данных.

    <ул>

  • <роль svg соответствует «img» viewbox = «0 8 несколько 11» xmlns = «http://www.w3.org/2000/svg»> Персонализированное признание
  • Ваши продукты и поддержка

    • Авторизоваться У вас нет аккаунта? Войти

    <ул>

  • Забыли пароль?
  • Об учетных записях Cisco

    • Cisco хочет, чтобы все сертификационные экзамены, включая CCNA, продемонстрировали способность каждого кандидата совершенствоваться наряду с отладкой рабочих сетей. Некоторые из нас используют маршрутизаторы Cisco ежедневно. Задачу других функция завершает, не разрешая повторный доступ к маршрутизаторам. Если к вам относится другое описание, ваша компания может следовать этому руководству, чтобы начать с маршрутизаторов и коммутаторов. В любом случае, этот раздел дает вам окончательное изложение некоторых связанных со сложными вопросами, связанными с протоколами пеленгации.

    Команда show ipРекомендации предоставляет множество стратегий, полезных в любое время при устранении неполадок в большой сети. Кроме того, команда протокола IP-адреса эпизода может предоставить много полезной дополнительной информации при устранении проблем с маршрутизацией. При наличии определенной небольшой ссылки большинство предложений по порядку отображения маршрутов ip являются излишними. Однако из-за того, что вы работаете с более крупными сетями, полезно помочь вам понять варианты и решения, которые может предложить каждая из них.

    В примере 6-21 перечислены параметры всех команд Set ip route и приведены некоторые из них. Рисунок 7-13 детализирует сеть; конструкция должна быть знакома по предыдущим примерам. В данном случае используется eigrp, соединяющий Альбукерке и Севилью, а RIP-2 фактически используется между Альбукерке и Йосемити. Между Йосемити и Севильей определенно нет ПВХ. Конфигурации любых трех перечисленных модемов показаны примерами 7-18, 7-19, затем 7-20. Пример 7-21 часто содержит опции show ip option.

    Рисунок 7-13 Сетевое окружение для использования с иллюстративными настройками IP-маршрутизации

    Рисунок 7-13 Сетевое окружение, используемое с параметрами маршрутизации для отображения IP-адреса

    <р> Пример 7-18. Настройка Albuquerque для параметров show ip track из примера 7-21

    <р> Пример 7-18. Настройка Альбукерке для показа опций маршрута с IP-адресом только в примере 7-21 (продолжение)

    Временная метка службы Временные рамки отладки Временная метка службы Время достижения Доступность журнала Нет плана обслуживания Шифрование паролей!

    Интерфейс Serial0 без IP-адресов без широковещательной IP-адресации Инкапсуляция Frame Relay IETF 56000 lmi-типа Cisco Frame Relay

    Двухточечный IP-адрес некоторых интерфейсов Serial0.1: 172.16.3.251 255.255.255. Нет трехнаправленных IP-адресов-широковещательного Frame-Relay-Interface-dlci 902

    Интерфейс serial0.2 точка-точка IP-боевой 172.16.1.251 255.255.255.0, чем ненаправленный IP-широковещательный-frame-relay-interface-dlci 903

    IP-протокол устранения неполадок навигации

    Пример 7-19. Настройка Yosemite для отображения параметров интернет-маршрута в примере 7-21

    Временная метка службы Время безотказной работы поддержки отладки. Служба временной метки подключения без единого шифрования!

    Интерфейс Serial0 null IP-адрес не IP Directed Broadcast Encapsulation Frame Relay IETF non Fair Queue Frame Relay lmi-type Cisco

    Интерфейс Serial0.1 Point-to-Point-IP правильный 172.16.3.252 255.255.255.0 просто нет направленного IP-Broadcast Frame-Relay-Interface-dlci 901

    Пример 7-20 Seville для обмена конфигурацией показывает все параметры IP-маршрута назад Пример 7-21

    <тр> <тд>

    Seville # показать текущую систему

    <тр> <тд>

    Текущая конфигурация. … 960 байт

    <тр> <тд>

    Версия 12.2

    <тр> <тд>

    Доступность отметки времени отладки службы

    <тр> <тд>

    Временная метка службы доступности дров

    <тр> <тд>

    сервисный пароль не защищен

    <тр> <тд>

    Имя хоста в Севилье

    <тр> <тд>

    Активировать секреты 5 ррр 1 $J3Fz$QaEYNIiI2aMu

    <тр> <тд>

    IP-подсеть с нулевым IP-адресом

    <тр> <тд>

    без поиска домена

    <тр> <тд>

    Интерфейс Serial0

    <тр> <тд>

    IP не концентрируется на

    <тр> <тд>

    вряд ли какая-либо направленная IP-трансляция

    <тр> <тд>

    Инкапсуляция Frame Relay IETF

    <тр> <тд>

    нет честной очереди

    <тр> <тд>

    Передача кадра по типу lmi Cisco

    <тр> <тд>

    Многоточечный интерфейс Serial0.1

    <тр> <тд>

    IP-адрес для 172.16.1.253 255.255.255

    <тр> <тд>

    определенно не направленная IP-трансляция

    <тр> <тд>

    Совокупный IP-адрес для нескольких eigrp 10.1.4.0

    <тр> <тд>

    Frame-Relay-Interface-dlci Serial1

    <тр> <тд>

    № 901

    <тр> <тд>

    Вывод интерфейса в Интернет

    <тр> <тд>

    нет IP-адресации

    <тр> <тд>

    Стоп

    <тр> <тд>

    Интерфейс Ethernet0

    <тр> <тд>

    IP, где они живут 10.1.4.253 255.255.255.0

    <тр> <тд>

    Интерфейс Ethernet1

    <тр> <тд>

    IP правильный 10.1.5.253 255.255.255.0

    <тр> <тд>

    Интерфейс Ethernet2

    <тр> <тд>

    IP боевой 10.1.6.253 255.255.255.0

    <тр> <тд>

    Интерфейс Ethernet3

    <тр> <тд>

    Отключить IP 10.1.7.253 255.255.255.0

    <тр> <тд>

    eigrp 9 маршрутизатор

    <тр> <тд>

    Сеть 10.0.0.0

    <тр> <тд>

    Сеть 172.16.0.0

    <тр> <тд>

    нет автоматического вывода

    <тр> <тд>

    Бесклассовый IP-адрес

    <тр> <тд>

    нет http IP-сервера

    Коды: C – подключенный, S – статический, I – IGRP, R – RIP, M – B мобильный, – BGP D – EIGRP, EX – внешний EIGRP, O – OSPF, IA – OSPF dis area N1 – OSPF NSSA Outdoor Space Type 1, N2 — OSPF Outside NSSA Type 2 E1 — Outside OSPF Type 1, E2 — Extniy OSPF style 2, E — EGP we — IS-IS, L1 — IS-IS level-1, L2 — IS-IS level – 2, при чем – IS-IS-Inter zone 6. – Кандидатный стандарт, U – определенный маршрут пользователя, o – ODR P – регулярно загружаемый статический маршрут

    172.16.0.0/24 поддерживает подсети, обычно всегда подключена подсеть C 172.16.1.0, Serial0.2

    10.0.0.0/8 с подсетями, несколько разных подсетей, 2 маски R 10.1.11.0/24 [120/1] через 172.16.3.252, 00:00:17, Serial0.1

    <таблица readabilitydatatable = «1»><тр> <тд>

    бгп

    <тр> <тд>

    пропитан

    <тр> <тд>

    например,

    <тр> <тд>

    eigrp

    <тр> <тд>

    Ускорьте свой ПК всего за несколько кликов

    Ваш компьютер работает медленно и нестабильно? Вас мучают таинственные ошибки, и вы беспокоитесь о потере данных или сбое оборудования? Тогда вам нужен ASR Pro — идеальное программное обеспечение для устранения неполадок Windows. С ASR Pro вы можете исправить широкий спектр проблем всего за несколько кликов, включая ужасный синий экран смерти. Приложение также обнаруживает аварийные приложения и файлы, поэтому вы можете быстро решить их проблемы. И самое главное, это совершенно бесплатно! Так что не ждите — загрузите ASR Pro прямо сейчас и наслаждайтесь бесперебойной, стабильной и безошибочной работой на ПК.

    играть

    <тр> <тд>

    isis

    <тр> <тд>

    Список

    <тр> <тд>

    Мобильный

    <тр> <тд>

    детская кроватка

    <тр> <тд>

    оспф

    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>

    3Ar

    q0Xm.

    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>

    255

    Как устранить ошибку переключения?

    Проверьте свой WiFi на разных устройствах.Перезагрузите основной персональный модем и маршрутизатор.Попробуйте использовать любой другой кабель Ethernet.Посмотрите, кто использует ваш собственный WiFi.Обновите свое оборудование.Позвоните предпочитаемому онлайн-провайдеру.Сбросьте этот маршрутизатор к настройкам просрочки.

    255.252.0

    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    <тд>
    устранение неполадок маршрутизации проекта ip

    Протокол пограничного шлюза (BGP)

    Подключено

    Как вы устраняете неполадки в протоколах построения курса?

    Фильтр протоколов и, следовательно, политика пеленгации Фильтры протоколов также называются списками управления соединениями (ACL).

    Протокол внешнего шлюза (EGP)

    Расширенный протокол маршрутизации внутренних шлюзов (EIGRP)

    Протокол маршрутизации внутреннего шлюза (IGRP)

    ISO IS-IS

    Список IP-доступа

    Мобильные маршруты

    Маршруты-заглушки при наложении

    Как узнать, работает ли моя маршрутизация?

    Чтобы проверить, работает ли ваш личный маршрутизатор, попробуйте выполнить эхо-запрос на компьютер с гораздо большим количеством компьютеров в той же сети. Обычно это возможно, если ваш информированный маршрутизатор работает правильно. Ваш персональный брандмауэр просто должен быть достаточно отключен.

    Сначала открыть кратчайший путь (OSPF)

    Загрузите это программное обеспечение сейчас и попрощайтесь с проблемами вашего компьютера. г.

    Ip Protocol Routing Troubleshooting
    Ip Protocol Routering Problemen Oplossen
    Solucion De Problemas De Enrutamiento De Protocolo Ip
    Depannage De Routage De Protocole Ip
    Rozwiazywanie Problemow Z Routingiem Protokolu Ip
    Risoluzione Dei Problemi Di Routing Del Protocollo Ip
    Ip Protokoll Routing Felsokning
    Solucao De Problemas De Roteamento De Protocolo Ip
    Ip 프로토콜 라우팅 문제 해결
    Fehlerbehebung Beim Ip Protokoll Routing
    г.

    Muhammad Hussain

    Muhammad Hussain

    Related posts:

    Простой способ устранения проблем с безопасным режимом на Audi A3 Chorus Radio

    Простой выбор для устранения проблем с BIOS Toshiba

    Самый щадящий способ устранения неполадок с помощью отличного диска восстановления системы

    Простой способ устранения ошибки Ts400

    • ← Erreur De Compilation Microsoft Vbscript 800a0400 Solution Facile
    • Conseils De Dépannage Pour Mettre à Jour Un Bios Asus →
    Источник

    Понравилась статья? Поделить с друзьями:
  • Устранение ошибок на линукс
  • Устранить ошибку память не может быть read
  • Устранить ошибку 651 подключения к сети
  • Устранение ошибок на диске виндовс 7
  • Устранение ошибок на ваз 2110