Сеть кольцо не работает

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

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

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

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

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

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

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

Чтобы найти сетевую петлю, нужно определить ее сначала по ее признакам. Благо, они четко определяемые и заметные. Для начала нужно закрепить 2 определения:

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

Любой сетевой пакет, пройдя через коммутатор в своем поле TTL , заполучает значение на одну единицу меньше. Так вот, очень уменьшенное значение TTL — это явный признак зацикленной локальной сети. Потому что низкий TTL объясняется тем, что пакет проходил много раз через маршрутизатор, с кажды м раз ом уменьшаясь. Его нормальное значение обычно не превышает 30. Уменьшаясь до единицы в сетевой петле, он потом «погибает».

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

Кроме того, наличие зацикленных пакетов приводит к существенному снижению пропускной способности канала свзяи. При этом проблема на одном из участков сети становятся причиной сбоев общих сетевых каналов связи. Однако ввиду того, что время жизни пакета (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-адресах, можно найти устройства, работа которых вызвала маршрутную петлю.

Источник

Петля в локальной сети: что такое и как найти

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

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

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

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

Поняв, что проблема, скорее всего, в неисправности коммутатора или кольце, я отправился в коммутационную. Там меня ждали три неуправляемых D-Link’а (это не оскорбление, а вполне себе термин для коммутатора).

Поначалу я всё же думал на неисправность коммутатора (тем более, что есть у меня субъективное недоверие к D-link). Количество портов трех 24-портовых коммутаторов для небольшого офиса на 10-15 машин было излишним, и оставалось еще от старых-добрых времен, когда компов в сетке было больше. Для вычисления виновника я по очереди выключал коммутаторы, и смотрел как на это отреагирует сеть. После нахождения нужного мне свича, все пользователи были переведены на оставшиеся два коммутатора, а я стал думать как вычислить нужный мне порт, ведь неисправен мог быть не весь коммутатор. Тогда ко мне и закралась мысль о кольце.

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

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

Итак, несколько советов как вычислить петлю в локальной сети:

1. Локализуйте проблему. Падает вся сеть или отдельный участок? Если у одного отдела сеть есть, а у другого нет, то проверяйте коммутатор, раздающий сеть на тот отдел.
2. Какой тип коммутатора(-ов) используется? Это может быть управляемый коммутатор или неуправляемый. В проблемном участке может быть и смесь из обоих вариантов. В случае с неуправляемым коммутатором придется вычислять проблемный порт методом научного тыка. В управляемом коммутаторе порты можно закрыть через веб-интерфейс.
3. Проверьте кабели. Скорее всего, дело всё-таки в физическом закольцевании сети. Но может «сдуреть» отдельно взятый порт в коммутаторе или сетевой плате компьютера. Редко, но может встретиться ситуация с дублированием функций DHCP-сервера, когда устройство (роутер, коммутатор или компьютер), которое этого делать не должно, раздаёт остальным некорректные настройки сети. В таком случае выключите DHCP-сервер и попробуйте получить адрес с какого-либо компьютера в проблемном участке сети. Если опасения подтвердились — проверяйте устройства на предмет включения функции DHCP-сервера. В первую очередь, конечно, роутеры и коммутаторы.

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

Источник

Закольцованные сети, или зачем нам STP

Суть проблемы

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

Иными словами, если свитч недавно получил пакет от компьютера А в порт 1, то в таблицу заносится соответствие «комп. А» -> «порт 1», и дальнейшие пакеты, адресованные компьютеру А, автоматически пересылаются только в порт 1, и никуда больше, что экономит пропускную способность сети и делает неэффективными пассивные перехватчики траффика.

Но что делать свитчу, если приходит широковещательный пакет (broadcast)?
Логично предположить, что такие пакеты пересылаются во все порты, кроме того, откуда изначально были получены.
Что, при определённой конфигурации сети, может привести к весьма печальным последствиям…

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

Что произойдёт, если свитчу 1 из облака придёт широковещательный пакет? Он размножит его и передаст в порты 1, 2 и 3 (из порта 4 пакет пришёл, так что обратно в него отправлен не будет). Свитч 2, получив пакет на 2 порту, отправит его копии в порты 1 и 3. Свитч 3, получив пакет на порту 1, отправит его копии в порты 2 и 3. Свитч 4, получив пакет на 3 порту, отправит его копии в порты 1 и 2. После чего каждая копия, передаваясь от устройства к устройству, будет размножена по этой же схеме всё больше и больше, пока суммарно они не займут всю доступную полосу пропускания (или не забьют мозги устройствам до потери их работоспособности).

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

STP спешит на помощь

Проблему вышеописанных «широковещательных штормов» решает запуск на свитчах протокола STP (или одного из его расширений).

Spanning Tree Protocol, или протокол простирающегося древа, приводит сеть к «древовидному» виду — с корнем и растущими из него «ветвями». Один из свитчей становится «корнем» (root bridge), затем все остальные рассчитывают «стоимость» (cost) достижения корня из всех своих портов, имеющих такую возможность (то есть, по сути, закольцованных где-то там, далеко), и отключают все неоптимальные линки. Таким образом, разрывая «петли». Если в дальнейшем в сети произойдёт сбой, и «корень» вдруг окажется недостижим через работающий порт, включится лучший из ранее заблокированных и связь будет восстановлена.

А теперь подробнее

Основной «рабочей лошадкой» STP являются Bridge Protocol Data Units aka BPDU. Это пакеты-«зонды», рассылаемые свитчами, и содержащие в себе:
1) идентификатор корневого свитча (Root ID);
2) идентификатор свитча, сформировавшего пакет (Bridge ID);
3) стоимость пути от второго к первому (Cost);
4) порт, из которого BPDU был исторгнут.

Предположим, сеть только что включили. Свитчи друг о друге ничего не знают. Нужно найти друг друга и выбрать, кто же станет «корнем» дерева. Свитчи дружно начинают сыпать во все порты BPDU, где указывают «корнем» себя любимого (Root ID).

STP работает так, что выйгрывает «выборы корня» свитч с самым низким Bridge ID, который состоит из двух частей: 2-байтный приоритет (по умолчанию 32768) и MAC-адрес свитча. Таким образом, если никаких настроек не производилось, и приоритеты у всех равны, выйграет свитч с самым маленьким MAC-адресом. Есть весьма отличная от нуля вероятность, что это будет самый старый (и, наверно, самый низкопроизводительный) свитч в организации, с закономерным итогом… Не забывайте об этом, друзья. Настраивайте приоритеты!

Итак, свитч с самым низким ID игнорирует принятые BPDU товарищей и продолжает гнуть свою линию — слать раз в 2 секунды свои BPDU, такие же точно, как самый первый. Он — «корень» топологии, он не будет отключать свои порты.
А вот остальные, получив BPDU со значением Root ID меньше, чем свой собственный Bridge ID, понимают, что «корень» — где-то там. Они перестают рассылать свои BPDU. Отныне и впредь, они просто ретранслируют BPDU «корневого» свитча, подставив на место Bridge ID себя, и пересчитав «стоимость» достижения «корня» (добавив к имеющейся в полученном BPDU свою долю).

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

Порт, из которого был получен корневой BPDU с наилучшей стоимостью, называется root-портом, он всегда работает. Порты, из которых получены корневые BPDU с худшей стоимостью, очевидно, ведут в «петли», от которых и нужно избавиться. Такие линки блокируются с одной стороны тем свитчом, чей Bridge ID ниже. Но блокируются не полностью, нам ведь надо иметь возможность вернуть их к жизни в случае сбоя. BPDU в таких линках продолжают отправляться и приниматься.
Если же Bridge ID в обоих пакетах одинаков (например, свитчи соединены более чем одним кабелем), выйгрывает тот, в котором указан меньший номер отправившего порта (Fa0/1 выйграет у Fa0/2).

Виды портов

В классическом STP, определённом стандартом 802.1d, порты могут быть такими:

1) Root port — ведёт к корню, имеет наименьшую стоимость среди собратьев, включён.
2) Designated port — ведёт не к «корню», а в какой-то сегмент сети, работает.
По понятной причине, у «корневого» свитча нет ни одного root порта. Все его порты — designated.
3) Blocked port — ведёт к корню и имеет нелучшую стоимость пути. Заблокирован для всего трафика, кроме BPDU. С другой стороны на этом линке — работающий designated port.

Состояния и переходы

Но самое, пожалуй, интересное — состояния портов. Выше я делил их всего на 2 — работает или заблокирован. На самом деле, их больше, по той простой причине, что работа STP — штука отнюдь не мгновенная, она требует времени. А создать шторм в сети — дело очень быстрое. Поэтому, «во избежание», так сказать, порты проходят через цепочку состояний в процессе работы.

1) Listening — порт включился (воткнули кабель/дали питание).
Передавать трафик страшно — а вдруг петля? Поэтому трафик не передаётся никакой, кроме BPDU. Ищем корень, прикидываем, какие порты будут работать.
Продолжительность — 15 секунд по умолчанию, диод на свитче моргает оранжевым.
2) Learning
Передавать трафик ещё страшно, но свитч уже принимает пакеты помимо BPDU, запоминает MAC-адреса в CAM-таблицу.
Продолжительность — 15 секунд по умолчанию.
3) Forwarding
Лампочка замигала радостным зелёным цветом, порт работает и передаёт данные.
4) Blocking/Disabled
Ну тут по названию всё ясно. Либо линк пришлось отключить, дабы не создавать петлю, либо порт административно выключен.

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

В случае сбоя в сети, где-то, где BPDU раньше ходили, они ходить перестают. И Blocked-порты, теперь получающие лучшие BPDU, выждав таймаут (20 секунд), переводятся в режим Designated, проходя цепочку состояний Listening — Learning — Forwarding (+30 секунд).
Таким образом, восстановление работоспособности сети может занимать до 50 секунд. Но, согласитесь, это гораздо лучше, чем неработоспособность после сбоя вообще.

И напоследок

Впоследствии, недостатки STP, о которых я упомянул (медленное восстановление работы сети), и о которых не упомянул, решались расширениями к протоколу.
Рассмотрим их вкратце.

1) RSTP (Rapid, быстрый)

Хранит в памяти кандидата на замену вышедшему из строя Root-порту (второе место по степени «наилучшести»), и способен очень быстро переключиться на него, не ожидая всех таймеров. Не получил 3 BPDU подряд на Root порте? Переключаюсь без лишних размышлений.

2) PVST+ (Per VLAN, по VLANный)

Зачем блокировать весь линк? Напрасная трата ресурсов! А давайте для каждого VLANа рассчитаем свою топологию STP, независимую. Таким образом, для одного VLAN будут одни линки заблокированы, а для другого — другие. Закон соблюдён и польза несомненна. При этом, в отправляемых BPDU номер VLANа хранится… в приоритете. 12 младших бит отданы под номер VLANа, а из 4 старших формируется, собственно, приоритет (имеющий при таком раскладе всего 16 легальных значений, с шагом 4096). Поле «приоритет» по умолчанию для VLAN 3 будет, таким образом, 32768 + 3 = 32771.

Cisco-проприетарный, сочетает свойства первых двух.

4) MSTP (Multiple)

PVST+ хорош, спору нет, но что если у нас over 9000 VLANов? Просчёт топологий для каждой из них может сильно загрузить процессор. Да и нужно ли это, если мы не занимаемся тонкой настройкой каждой полученной топологии? MST позволяет сгруппировать VLANы в т.н. instance (наборы), рассчитывая топологию уже для этих, более крупных образований.

В процессе написания

Использовались википедия и остатки знаний курса CCNA в голове.

Источник