Петля в сети ethernet что это
Перейти к содержимому

Петля в сети ethernet что это

  • автор:

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

Петля коммутации (Bridging loop, Switching loop) — состояние в сети, при котором происходит бесконечная пересылка фреймов между коммутаторами, подключенными в один и тот же сегмент сети.

[править] Описание

Пример топологии

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

  1. Компьютер PC-1 отправляет фрейм компьютеру PC-4;
  2. Коммутатор А первым получает фрейм и заносит в таблицу коммутации адрес компьютера PC-1 с исходящим портом 1/1;
  3. Так как коммутатор А не знает местоположение(порт подключения) получателя фрейма, он рассылает фрейм через все свои активные порты, кроме порта, из которого этот фрейм был получен;
  4. Коммутатор В получает фрейм от компьютера PC-1 и производит аналогичные манипуляции;
  5. Компьютер PC-4 получает две копии фрейма — один от коммутатора А, другой от В;
  6. Одновременно с этим, копию фрейма от коммутатора А через сегмент B получает коммутатор В. Так как для В полученная копия является «новым» фреймом, то он производит стандартный процесс коммутации фрейма:
    1. Так как MAC-адрес источника идентичен предыдущему фрейму из сегмента А, он удаляет из своей таблицы коммутации запись для компьютера PC-1 с портом 1/1 и добавляет новую запись для PC-1 с портом 2/1;
    2. Рассылает фрейм по всем активным портам, кроме порта, из которого фрейм был получен(2/1);

    Тем самым происходит бесконечное циркулирование фрейма между сегментами сети.

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

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

    [править] Методы предотвращения

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

    Канальный уровень
    Основные понятия Коммутация • MAC-адрес • Сетевой интерфейс • CAM-таблица • VLAN • Broadcast • Multicast • Unicast • ifconfig • QinQ
    Петли коммутации и борьба с ними
    Ключевые понятия Широковещательный шторм • Петля коммутации • Остовное дерево
    Протоколы STP • RSTP • MSTP • PVST • PVST+
    Настройка STP на коммутаторах Cisco • коммутаторах ProCurve
    Агрегирование каналов
    Ключевые понятия Агрегирование каналов • EtherChannel
    Протоколы LACP • PAgP
    Настройка в Linux • FreeBSD • NetBSD • OpenBSD • Mac OS X • Solaris • Windows • маршрутизаторах Cisco • коммутаторах Cisco • коммутаторах ProCurve
    Протокол ARP
    Ключевые понятия Протокол ARP • ARP-таблица • Статический ARP • Proxy ARP
    Программы arp • arping • arp-sk • arpmap
    Виртуальные и программные коммутаторы, мосты и сетевые интерфейсы
    Компоненты tap-интерфейс • dummy-интерфейс • Мост в Linux • Мост в FreeBSD • vde • OpenVPN Bridge
    Программы brctl (man) • ebtables
    Безопасность
    Программы и библиотеки Wireshark • Scapy
    MAC MAC-spoofing • Port security • Поиск по MACу • MAC-spoofing в виртуальной машине
    ARP ARP-spoofing • ettercap • arpwatch (man) • remarp • Dynamic ARP Protection

    Loopdetect своими руками

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

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

    Матчасть

    К счастью большинство современных управляемых коммутаторов, в том или ином виде, имеют функции выявления петель (loopdetect, stp), и даже более того, семейство протоколов stp позволяет специально строить кольцевую топологию (для повышения отказоустойчивости и надёжности). Но тут есть и обратная сторона медали, не редко случается так, что один сгоревший порт может оставить без связи целый район. Или скажем у того же stp перестроение топологии происходит далеко не мгновенно, связь в этот момент, естественно, оставляет желать лучшего. Кроме того, некоторые производители весьма халатно относятся к реализации протоколов обнаружения петель, скажем DES-3016 (глинк) вообще не может определить петлю если просто соединить два его порта.

    Принципы выявления

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

    Если вся сеть управляемая, то выявить и устранить петлю довольно не сложно. Но не так уж мало сетей где к одному порту подключена цепочка из 5 — 6 неуправляемых коммутаторов. Устранение такой петли может занять немало времени и сил. Процесс поиска же сводится к последовательному отключению (включению) портов. Для определения наличия петли используется либо вышестоящий управляемый коммутатор, либо какой-нибудь снифер (wireshark, tcpdump). Первый способ весьма опасен в следствие наличия задержки между включением и выключением блокировки, в лучшем случае у пользователей просто будут лаги, а в худшем — сработает loopdetect выше по линии и отвалится уже куда больший сегмент. Во втором случае опасности для пользователей нет, но зато намного сложнее определять наличие петли (особенно в небольшом сегменте, где мало броадкаст трафика), всё-таки снифер вещь, по определению, пассивная.

    Своими руками

    Как было сказано выше, аппаратных реализаций поиска петель хватает с лихвой. Так что не долго думая, включаю wireshark настраиваю фильтр и смотрю, что и как делает коммутатор. Собственно всё просто: в порт отправляется пакет ethernet с адресом назначения cf:00:00:00:00:00, типом 0x9000 (CTP) и c неведомым номером функции 256 (в найденной мной документации описаны только две). Адрес назначение является броадкастовым, так что при наличии в сети петли назад должно вернутся несколько копий этого пакета.

    • Для захвата и отправки сырых пакетов воспользуюсь библиотекой pcapy;
    • С генерацией пакетов мне поможет dpkt;
    • Для воспроизведения звука воспользуюсь pyaudeo и wave;
    • Ну и несколько стандартных библиотек.

    С получившимся скриптом можно ознакомится далее.

    import pcapy, dpkt , sys import time , random, socket import pyaudio , wave def packetBody(length): rez = [] for x in range(0,length): rez.append(random.choice('0123456789abcdef') + random.choice('0123456789abcdef')) return rez class loopDetector: packetCount = 0 loopCount = 0 timeout = 1 def __init__(self,iface): self.iface = iface self.pcaper = pcapy.open_live(iface,100,1,500) self.Mac = '00:19:5b:'+':'.join(packetBody(3)) self.pcaper.setfilter('ether dst cf:00:00:00:00:00 and ether src %s' % self.Mac) wf = wave.open('alarm.wav', 'rb') self.pyA = pyaudio.PyAudio() self.stream = self.pyA.open(format = self.pyA.get_format_from_width(wf.getsampwidth()), channels = wf.getnchannels(), rate = wf.getframerate(), output = True) self.wfData = wf.readframes(100000) wf.close() def __del__(self): self.stream.stop_stream() self.stream.close() self.pyA.terminate() def PlayAlarm(self): self.stream.write(self.wfData) def Capture(self,hdr,data): if data == str(self.sPkt): self.packetReceived += 1 def Process(self): while 1: try: pktData = '00000001' + ''.join(packetBody(42)) self.sPkt = dpkt.ethernet.Ethernet(dst="cf0000000000".decode('hex'), src=''.join(self.Mac.split(':')).decode('hex'), type=36864,data=pktData.decode('hex')) endTime = time.time() + self.timeout print "Send packet to %s" % self.iface self.packetCount += 1 self.pcaper.sendpacket(str(self.sPkt)) self.packetReceived = 0 while time.time() < endTime: try: self.pcaper.dispatch(-1,self.Capture) except socket.timeout: pass if self.packetReceived >1: self.loopCount += 1 print "Loop Detected. Duplication found %s" % self.packetReceived self.PlayAlarm() except KeyboardInterrupt: break print "Packets sent: ", self.packetCount , "Loops discovered : " , self.loopCount def main(): dev_list = <> n = 0 iface = '' for x in pcapy.findalldevs(): dev_list[n] = x n += 1 try: iface = dev_list[0] except KeyError: print "No device found" exit(1) if len(sys.argv) == 2: try: if sys.argv[1] in ['list','ls','all']: for x in dev_list: print 'Index:', x, 'Device name:' ,dev_list[x] return 0 else: iface = dev_list[int(sys.argv[1])] except KeyError: print "Invalid device id, trying use first" iface = dev_list[0] ld = loopDetector(iface) ld.Process() if __name__ == "__main__": main() 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Коммутационные патч панели

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

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

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

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

    Коммутатор на 50 портов

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

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

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

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

    Порты свитча, создающие петлю в сети

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

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

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

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

    Петля передачи данных на коммутаторе

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

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

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

    Коммутационный шкаф

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

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

    Тестер для локальной компьютерной сети

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

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

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

    Порты патч панели

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

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

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

    Сетевые розетки пользователей

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *