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

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

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

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

          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-адресов на порт
• Включите Option82, если вы запускаете DHCP

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

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

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

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

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

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

 storm-control broadcast level 5.00  
 storm-control action shutdown

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

Хотя по твоему актуальному вопросу, я всегда считал, что это руководство.

для IOS:

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

sh logg

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

sh int g0/1 controller

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

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

sh proc cpu

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

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

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

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

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

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

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

Уч. Но хорошо, я могу придумать два пути, по которым я могу пойти на это ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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