Чем опасно появление петель коммутации

Как найти петлю в локальной сети и как ее оперативно устранить

Сетевая петля — на самом деле , опасная штука. Очень часто ее появление связано с неправильным подсоединением линков маршрутизаторов или коммутаторов. Реже она случается из-за неверных настроек маршрутного адреса.

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

Как образуется сетевая петля

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

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

Как определить сетевую петлю по ее признакам

1. TTL — это временное ограничение жизни сетевого пакета;
2. IP ID — это и так понятно.

Как найти сетевую петлю в локальной сети

1. Первое , что нужно сделать , — это определить локальный участок, где происходит зацикливание. Определить н ет рудно — там возникают проблемы с И нтернетом.
2. Подберите любой сниффер и можете его запускать для определения зацикленных устройств.
3. Определите сетевые пакеты, создающие шторм , и отфильтруйте их. Найти их будет н ес ложно — их огромное количество и у многих схожий ID IP.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Образование петли и нарушение работоспособности локальной сети с помощью программного обеспечения GNS3

Дисклеймер : Мы не несем ответственность за Ваши действия и не призываем Вас к каким-либо действиям! Все материалы взяты с открытых источников, опубликованы для образовательных целей.

Оглавление

1. Широковещательный шторм в состоянии петли
2. Методы предотвращения
3. Создание широковещательного шторма (петли)
4. LLMNR
5. Анализ последствий

1. Широковещательный шторм в состоянии петли

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

Рис.1 Пример петли в локальной сети

Рис. 2 Пример топологии сети

Пример топологии, рассматриваемой сети, изображен на рисунке 2.

Компьютер ПК-1 отправляет кадр (frame) по сети через коммутатор компьютеру ПК-N. Коммутатор получает кадр и в таблицу коммутации заносит адрес компьютера ПК-1 с портом. Коммутатор не знает где расположен порт получателя кадра, кроме порта, из которого этот кадр был получен. Соответственно, кадр получает ПК-N и получает виртуальный коммутатор GNS3 (далее будет подробно показано, как реализовать виртуальную сеть с помощью GNS3). Виртуальный коммутатор GNS3, который расположен в ПК-N, производит аналогичные действия. Компьютеры расположенные в локальной сети получают несколько кадров — один от коммутатора локальной сети, другой от виртуального коммутатора. Одновременно с этим, копию кадра от коммутатора локальной сети получает виртуальный коммутатор GNS3. Так как для виртуального коммутатора копия является “новым” кадром, то он производит стандартный процесс коммутации кадра. Тем самым происходит бесконечное циркулирование кадра между сегментами сети.

2. Методы предотвращения

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

3. Создание широковещательного шторма (петли)

Рассмотрим проблему создания петли в сетевом программном эмуляторе GNS3 . GNS3 позволяет комбинировать виртуальные и реальные устройства, используемые для моделирования сложных сетей. Он использует программное обеспечение эмуляции Dynamips для имитации Cisco IOS . Для создания петли воспользуемся одним из способов подключения GNS3 к реальной физической сети. Этот способ возможен, если компьютер подключен к коммутатору (к локальной сети). Схема изображена на рисунке 3.

Рис. 3 Схема соединения 2 хостов и 1 коммутатора

У хостов в качестве интерфейса указываем “ nio_gen_eth:Ethernet N ”.

Перед этим проведем анализ трафика в сети с помощью ПО Wireshark (рис. 3).

Рис.4 Анализ трафика в сети с помощью Wireshark

В среднем в сети проходит 5-10 пакетов в секунду. Основной пакет — это LLMNR , который в последствии будет являться причиной нарушения работоспособности коммутатора. Сначала стоит разобрать сам протокол LLMNR .

4. LLMNR

LLMNR , англ. Link-Local Multicast Name Resolution — протокол стека TCP/IP , основанный на формате пакета данных DNS , который позволяет компьютерам выполнять разрешение имен хостов в локальной сети. Для LLMNR выделены порты 5355/UDP и 5355/TCP, в IPv4 выделен широковещательный адрес 224.0.0.252 и MAC-адрес 01-00-5E-00-00-FC, в IPv6 — FF02:0:0:0:0:0:1:3 (сокращённая запись — FF02::1:3) и MAC-адрес 33-33-00-01-00-03.

Рис. 5 Структура заголовка пакета LLMNR

Служба LLMNR ( Link-Local Multicast Name Resolution ) позволяет организовать одноранговое разрешение имен в пределах одной подсети для IPv4 , IPv6 или обоих видов адресов сразу без обращения к серверам, на что не способны ни DNS , ни WINS . WINS предоставляет как клиент-серверную, так и одноранговую службу разрешения имен, но не поддерживает адреса IPv6 . DNS , с другой стороны, поддерживает оба тина адресов, но требует наличия серверов. Разрешение имен LLMNR , работает для адресов IPv6 и IPv4 в тех случаях, когда другие службы разрешения имен недоступны, например, в домашних сетях, в небольших предприятиях, во временных сетях или корпоративных сетях, где по каким-то причинам недоступны DNS -службы. Поскольку трафик LLMNR не проходит через маршрутизаторы, вы не рискуете случайно заполнить им сеть.Как и WINS , LLMNR позволяет преобразовать имя хоста в IP -адрес. По умолчанию LLMNR включен на всех компьютерах под управлением Windows . Эти компьютеры прибегают к LLMNR , если попытки узнать имя хоста через DNS окончились неудачей. В результате, разрешение имен в Windows работает следующим образом:

1. Хост посылает запрос на первичный DNS -сервер. Если он не получает ответа или получает сообщение об ошибке, он по очереди посылает запросы на все вторичные DNS — серверы. Если и это не помогло, разрешение имени передается LLMNR .
2. Хост посылает многоадресный UDP -запрос, запрашивая IP -адрес для нужного имени компьютера. Этот запрос идет только по локальной подсети.
3. Каждый компьютер локальной подсети, поддерживающий LLMNR и сконфигурированный для ответа на поступающие запросы, сравнивает имя со своим хост-именем. Если они не совпадают, компьютер отбрасывает запрос. Если имена совпадают, компьютер пересылает исходному хосту одноадресное сообщение с ІР -адресом.

5. Анализ последствий

Компьютеры с LLMNR должны проверять уникальность своих имен в подсети. В большинстве случаев это происходит при запуске, восстановлении из спящего режима или при смене параметров сетевого интерфейса. Если компьютер еще не проверил уникальность своего имени, он должен указывать это в ответе на запрос. После создания петли в GNS3 (рис. 3), увидим некоторые особенности в Wireshark (рис. 6).

Рис. 6 Количество пакетов в сети

Рис. 7 Загруженность пропускной способности канала передачи

Рис. 8 Отключение сетевых дисков №1 и №2

Рис. 9 Анализ трафика с помощью Wireshark после создания петли

После создании петли сразу же в сети наблюдается рост количества пакетов к экспоненциальному росту их числа и парализует работу сети. Это состояние в сети называется широковещательный шторм. Широковещательный шторм — лавина широковещательных пакетов (на втором уровне модели OSI — кадров). Считается нормальным, если широковещательные пакеты составляют не более 10 % от общего числа пакетов в сети.Довольно часто к широковещательному шторму приводят петли в сети при неправильной настройке канального протокола Spanning Tree . Spanning Tree Protocol (STP) — канальный протокол. Основной задачей STP является устранение петель в топологии произвольной сети Ethernet, в которой есть один или более сетевых мостов, связанных избыточными соединениями. STP решает эту задачу, автоматически блокируя соединения, которые в данный момент для полной связности коммутаторов являются избыточными.

Петля в локальной сети. Как найти и устранить?

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

Заранее узнать появление петли очень трудно, а при её возникновении сеть просто «ложится». Одна локальную петлю можно «диагностировать» по ряду признаков, которые показывают зацикливание пакета информации

Формирование петли в локальной сети

Маршрутная петля появляется, когда пакет отправителя не может попасть получателю и длительное время движется по одному маршруту – он «зацикливается» в одном участке сети

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

И мы в ответ получаем сообщение

При этом сеть на данном участке оказывается перегруженной и «падает». Перегружают её пакеты которые не могут покинуть петлю – формируется широковещательный шторм.

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

Петля в локальной сети: Характерные признаки

Сетевая петля обладает совершенно четкими признаками, этими признаками является ряд параметров

Time to live (TTL) время жизни пакета

IP ID идентификатор IP пакета

IP пакет, проследовав через маршрутизатор,в поле TTL получает значение. Явным признаком «зацикленного» пакета становится низкое значение TTL, после чего IP-пакет просто уничтожается роутером. Низкий показатель не обязательно показывает петлю в сети, это ещё может быть характеризовано что пакет прошёл слишком много маршрутизирующих устройств. Как правиль, в зацикленной сети появляется слишком много пакетов с одинаковы идентификаторов. При этом пакетов одновременно может возникнуть несколько тысяч.

Как искать петлю в локальной сети?

Анализатор сетевого трафика (сниффер) поможет не только выявить наличие маршрутной петли, но и покажет сетевые устройства, которые ее создали. Конечно, можно подергать каждый патч-корд каждого сетевого устройства, однако такое решение нерационально для корпоративной сети.

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

2. Запустить сниффер с целью определения устройств, между которыми осуществляется столь «эмоциональное» общение.

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

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

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

6. Обладая сведениями о MAC-адресах, можно найти устройства, работа которых вызвала маршрутную петлю.

Петля в локальной сети и ее последствия

Прежде всего: что такое петля в сети? Это — логическое кольцо для проходящего сигнала, когда запараллелены пути его прохождения. Грубо говоря можно сказать так: когда сигнал вместо того, чтобы от коммутатора разойтись по подключенным к нему компьютерам возвращается обратно в коммутатор и так продолжается бесконечно (по кругу). Возникает логическая "петля" (кольцо).

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

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

И вот, сижу я как-то на 11-м этаже нашего здания, компьютер настраиваю. Делаю что-то локально, не связанное с сетью. Краем уха слышу через два стола: "Интернет не грузится. " Ну, думаю, не грузится и не грузится. мало ли что? Тут — из другого конца помещения: "Ой, на сетевые диски зайти не могу!". Тут я уже насторожился и решил "пропинговать" один из наших внутренних серверов.

Каково же было мое удивление, когда я увидел временные задержки выполнения команды "ping". Они были более ста миллисекунд! Это, повторюсь, — в локальной сети, а последний пакет данных вообще не дошел до адресата. На всякий случай — перезагрузил компьютер, за которым сидел (мало ли что?) — никаких изменений, и вдобавок сетевые диски, которые автоматически монтируются при загрузке операционной системы — "отвалились".

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

Да-а-а. думаю, а день так хорошо начинался! 🙂 Делать нечего — беру ключи и иду к этому коммутационному центру нашей СКС (структурированной кабельной системы) сети.

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

Открываю, значится, его и заглядываю внутрь:

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

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

Теперь делаем наоборот: включаем нижний свитч и выключаем верхний. Проверяем с компьютера, подключенного к нижнему коммутатору. Работа сети восстановилась в полном объеме: «ping» проходит без задержек, после перезагрузки подмонтировались сетевые диски!

Значит — проблема в верхнем коммутаторе, либо — в подключенных к нему патч кордах (коротких сетевых кабелях). Итак, посмотрим на эти самые патч корды, которыми наш коммутатор соединяется с патч панелями в кроссовом шкафу.

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

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

После извлечения очередной пары кабелей (примерно на середине свитча) работа сети неожиданно (или — ожидаемо) восстанавливается! 🙂 Та-а-ак. методом нескольких дополнительных подключений и отключений находим один порт на коммутаторе, после подключения к которому сеть "ложится"!

Похоже — битый порт? Но тут я замечаю одну очень неожиданную вещь! Обратите внимание на фото ниже:

При вытягивании кабеля из порта под номером «21» (того самого, найденного нами) гаснет светодиод на порте под номером «19». Оба кабеля обведены для наглядности красным. Верхний ряд свитча — порты с нечетными номерами.

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

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

Примерно вот так:

Но тогда получается, что кто-то намеренно вскрыл запертый кроссовый шкаф, создал эту "петлю", аккуратно спрятал среднюю часть кабеля за лицевую панель в шкафу, закрыл его обратно и где-то затаился? Бред какой-то! 🙂 Да и кому это нужно?

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

Вот — результат моей деятельности:

Обратите внимание на два кабеля, обозначенные красным. Дело в том, что эти именно два разных кабеля! Фирменные патч корды, которые мы используем для коммутации в СКС шкафу достаточно короткие (сантиметров 40), поэтому четко видно, что это не один а два разных патч корда.

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

Кабель "прозванивается", как один цельный отрезок!

Что это?! Один длиннющий нестандартный патч корд? Я такого у нас никогда не видел, но. все может быть. Подсознательно понимая, что дело не в этом, выясняю куда ведут два скрытых внутри шкафа конца этого кабеля (кабелей)?

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

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

Пользовательские розетки. В голове забрезжила какая-то мысль и — опа! Мозг "ухватил" ее и вытащил на поверхность! Догадались о чем это я? Кто нет — за мной! Искать на этаже розетки под номером «28» и «32» 🙂

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

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

Интересующий нас кабель обозначен с двух сторон красным, а его центральную часть я (для наглядности) скрутил на полу "бубликом". Это — непрерывный отрезок кабеля, который замыкает между собой коммутационные розетки под номерами «28» и «32», заворачивая, тем самым, передаваемый по сети сигнал в обратную сторону (к коммутатору).

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

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

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

Телефонный кабель порвался, клубок кабелей, лежащий на полу под розетками, — разлетелся и в результате все, что подходило по форме и диаметру — было воткнуто тем же менеджером в свободные СКС розетки. Потому что — порядок должен быть в офисе! 🙂 Вот таким естественным образом возникло наше кольцо!

Но, как говорится: "Кто предупрежден, тот — вооружен!". Поэтому я искренне надеюсь что этот материал поможет Вам в будущем, если не избежать, то, по крайней мере, быстро выявить и устранить возникшую петлю в локальной сети. И, коллеги, не очень строго наказывайте своих пользователей, потому что не ведают они что творят и не со зла, а по незнанию совершают админо-неугодные свои действия 🙂