Как я могу диагностировать петлю моста (ethernet)?

Учитывая, что связующее дерево потерпело неудачу (или у вас нет какого-либо связующего дерева) и получить цикл ethernet, как лучше всего диагностировать, где проблема?

Какой переключатель ?, какой кабель? и т. д.

41 голос | спросил nos 15 Maypm13 2013, 14:19:22

15 ответов


28

ОК, предположим, что у вас есть топология вроде:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

По какой-то причине существует контур моста, STP отключен или кто-то применил фильтр не в том месте или таком.

ПК A хочет общаться с ПК B. Это первые ARP для MAC ПК B, назначение - трансляция с MAC ffff.ffff.ffff. Таким образом, кадр переходит к SW1 и SW3. SRC MAC - это ПК A. Затем SW1 наводняет кадр в сторону SW3, а SW3 будет заливать кадр, идущий от SW2 до SW1.

SW1 и SW3 узнали MAC на ПК A, когда вошел первый кадр. Когда второй идет в противоположном направлении, он должен переучивать его. Поскольку эти события происходят так быстро и многократно, вы увидите сообщения журнала, жалующиеся на раздувание MAC. Что-то вроде «MAC FLAP 0000.0000.0001 хлопает между Gi0 /24 и Gi0 /23». Это хороший признак того, что у вас есть цикл.

Что вы можете сделать, так это попытаться проследить этот MAC. Попробуйте искать в кэше ARP устройства в той же подсети и посмотреть, какой IP это устройство имеет. Таким образом, с помощью MAC вы можете попытаться отследить его с помощью sh mac-address-table или с IP, возможно, у вас есть список со всеми IP-адресами и где они подключены.

Если хост получает IP-адрес от DHCP-сервера, вы также можете попробовать найти, откуда идет хост. Если у вас включен вариант 82, это будет большой помощью.

Другие признаки того, что CLI будет очень вялым. Загрузка процессора будет очень высокой. Коммутаторы делают почти все в ASIC, поэтому, если коммутатор имеет нагрузку на процессор более 50%, это, вероятно, не очень хорошо. Вы должны реализовать мониторинг SNMP и наблюдать за высокой загрузкой процессора. Также ищите сообщения MAC-лоскута. Если переключатели имеют петлю, светодиоды, вероятно, будут мигать как сумасшедшие.

Что вы можете сделать для защиты от циклов:

  • Включить STP! (Дух)
  • SNMP-мониторинг загрузки процессора
  • Включить ловушки SNMP для определенных событий, таких как изменения топологии STP.
  • Включить управление штормом на портах для ограничения широковещательной передачи
  • Не допускайте чрезмерных изменений в ваших VLAN в топологии L2.
  • Включить защиту порта и ограничение количества MAC-адресов на порт
  • Включить параметр82, если вы запустите DHCP
ответил Daniel Dib 15 Maypm13 2013, 15:29:51
20

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

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

ответил Dennis Olvany 15 Maypm13 2013, 16:03:37
10

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

Для большого шасси (например, 6500) мне пришлось вытащить все лезвия и подключить их обратно по одному. Как только я понял, какой клинок, мне пришлось вытащить все отдельные ссылки (16 GBIC) и вернуть их обратно по одному. Никогда не веселитесь.

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

ответил Peter 15 Maypm13 2013, 16:11:02
10

Недавно я начал работать в компании, где они используют ограничения на вещание для каждого порта. Если порт пропускает> 5% от его пропускной способности, как передается, коммутатор помещает его в ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

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

Хотя для вашего фактического вопроса я всегда считал его ручным.

ответил Scott Boultinghouse 15 Maypm13 2013, 20:00:06
8

для IOS:

Вероятно, у вас будут MAC-адреса, переключающиеся между портами. Ищите MAC_MOVE_NOTIFICATION (или подобные) ошибки в:

sh logg

Теперь, чтобы найти порт:

sh int g0/1 controller

найдите вне обычных Multicast и Broadcast номеров. Любые столкновения являются плохим признаком.

И последнее, но не менее важное: вы не можете войти в систему, потому что CPU выложен:)

sh proc cpu

Как здесь работает переключатель? Если это только переключатель L2, вам не нужно ничего выше ~ 10%

ответил yeled 15 Maypm13 2013, 15:53:38
8

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

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

  • Во-первых, подключите устройство для сброса пакетов /устройств, поддерживающих обнюхивание, к порту в один из переключателей. Теперь это устройство стало корневым устройством вашего дерева.
    • Если вам нужно найти неисправность в нескольких местах, например. над «кампусом» или подобным, вы выиграете, имея возможность удаленно входить в систему с помощью портативного ssh-клиента на машину для пакетной демпинга.
      • Я лично использовал свой Linux-ноутбук с подключением к Интернету с tcpdump на экране и ssh в него, например, с помощью ipad или телефона.
    • Если вы не можете войти в систему удаленно, используйте друга, чтобы визуально отслеживать tcpdump, который, вероятно, наводняет скорость связи, что позволяет легко заметить разницу, когда отключен путь к исходному устройству loop.
  • Затем вам нужно будет по существу воссоздать дерево, начиная с вашего корневого коммутатора.
    1. И поскольку у вас может быть сценарий, в котором у вас есть несколько циклов связи, загружаемых в ваше корневое устройство, вы должны начать с одновременного удаления всех подключенных портов одновременно.
    2. Повторно подключите порты по одному, и если в любой момент снова появится пакетный пакет, следуйте этому порту на подключенный коммутатор на другом конце.
    3. Повторите шаг 1, пока не найдете зацикленный порт (-ы) и не можете продолжать итерацию в своем дереве вручную.
    4. Устраняя ситуацию цикла в этом коммутаторе, вернитесь к переключателю выше в дереве и повторите шаг 2. Эта рекурсия продолжается до тех пор, пока последний кабель не будет повторно подключен в вашем корневом коммутаторе.

Это полностью исчерпывающий ручной поиск зацикленных портов.

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

Тем не менее, общий, «грязный», метод или алгоритм становится тем, что я описал выше.

ответил Anticimex 16 Maypm13 2013, 13:50:05
6

Уч. Но хорошо, я могу подумать о двух способах, которыми я бы это сделал ...

Eyeball it: Если у коммутаторов есть индикаторы портов, вы должны иметь возможность наблюдать за тем, какие порты наиболее активны. Это те, с которых нужно начинать смотреть в первую очередь. Надеемся, что кабели будут помечены так, чтобы вы могли искать плохие плоды поиска двух загруженных портов на двух коммутаторах с одним и тем же кабелем.

Мониторинг SNMP: если у вас есть статистика использования SNMP (или аналогичного), найдите самый загруженный коммутатор и самые загружаемые порты. Затем посмотрите на кабели.

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

ответил Craig Constantine 15 Maypm13 2013, 14:58:58
3

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

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

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

ответил Jamie 21 Mayam13 2013, 11:07:00
2

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

Если его коммутатор Cisco, 2 простых, чтобы посмотреть статистику интерфейса, он будет на 100% (или 255/255) использования, постоянно. В мои годы работы с коммутаторами я еще не видел, что порт легитимно ударил по 100% использованию. Помимо этого, проверьте использование ЦП (как правило, «show process cpu history»), замкнутые интерфейсы обычно сильно ударяют ваш процессор, если вы не используете высокопроизводительный коммутатор.

STP действительно должен быть включен, хотя!

ответил Artanix 15 Maypm13 2013, 15:07:11
2

У меня возникла эта проблема в сети на другом конце США, и мне приходилось дистанционно помогать аналитикам одного уровня по телефону и моей ссылке wan на свой сайт. Проблема осложнялась еще тем, что у них было несколько марок коммутаторов, которые они медленно добавляли в сеть на протяжении многих лет. Когда они переехали в офис, они отметили, что каждый порт пошел, а затем снова привязал все то же самое в новом офисе и начал все. Само собой разумеется, что несколько переключателей, у которых было рабочее перекрывающее дерево, не сходились одинаково, и у них были все виды циклов и проблем. К тому моменту, когда я закончил работу, было обнаружено, что не менее трех неуправляемых коммутаторов были подключены в петлях с остальной инфраструктурой.

То, как я смог отслеживать каждый из неуправляемых коммутаторов, был с помощью инструмента nedi (на коммутаторах, которым удалось управлять, я включил lldp /cdp). Сначала я создал карты с nedi. Затем в областях, где на карте показывались соединения от одного коммутатора к другому, затем обратно к тому же коммутатору снова, у меня был сетевой техник на сайте, который отслеживает линию вручную. Я либо вручную отключил интерфейсы, связанные с циклом, либо отсоединил кабели на месте. В конце концов, я смог заставить сеть работать должным образом, несмотря на все сумасшедшие переключатели бренда.

ответил Zachary Loeber 16 Mayam13 2013, 07:57:37
1

Одна вещь, которую можно сделать здесь, - посмотреть, какие машины подключены к коммутатору, используя команды show cdp neighbor или show lldp neighbor.

Если команда охраны BPDU не используется, а кто-то подключает коммутатор-изгои с более низким приоритетом (или более старым mac-адресом), новое устройство будет согласовывать его с корнем Spanning Tree, что, несомненно, вызовет проблему.

ответил ahtesham quraishi 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 09 Sep 2013 16:19:47 +0400 2013, 16:19:47
0

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

ответил Dave Noonan 15 Maypm13 2013, 15:06:42
0

Определение цикла действительно зависит от используемого вами ключа коммутатора. Например, на коммутаторе Extreme я могу запускать elrp-клиент в VLAN, и коммутатор будет в основном отправлять широковещательный фрейм на всех портах для этой VLAN и видеть, возвращается ли он каким-либо из них, если это так, он сообщает мне, какой порт (ы), на который был получен фрейм, тем самым выявляя кандидатов цикла.

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

ответил Olipro 15 Maypm13 2013, 21:07:20
0

Без сомнения, самый быстрый подход, который я нашел, - это контролировать скорость передачи пакетов /сек. Интерфейсы быстрого отображения с соответствующим фильтром CLI будут перечислять каждый интерфейс и скорость передачи пакетов /сек. Чтобы найти источник петли, найдите единственный интерфейс с сумасшедшей скоростью передачи пакетов /сек. INPUT. В типичной корпоративной среде, с типичными профилями использования, она работает каждый раз без сбоев. На 6500 с множеством интерфейсов не требуется очень много времени, чтобы определить источник ...

ответил Pete Moorey 21 Maypm13 2013, 12:18:22
0

В течение цикла для большого количества широковещательного трафика (например, запроса ARP) на конечной станции может также увеличиться нагрузка на CPU (например, если вы используете недорогую карточку Realtek 100 Мбит /с, которая вычисляет контрольную сумму на ЦП) , Как физически можно найти петлю, если кабель отсоединен, ссылка сразу же потеряна на 2 портах.

ответил t3mp 4 WedEurope/Moscow2013-12-04T06:56:32+04:00Europe/Moscow12bEurope/MoscowWed, 04 Dec 2013 06:56:32 +0400 2013, 06:56:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132