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() Как найти петлю в локальной сети и как ее оперативно устранить
Сетевая петля — на самом деле , опасная штука. Очень часто ее появление связано с неправильным подсоединением линков маршрутизаторов или коммутаторов. Реже она случается из-за неверных настроек маршрутного адреса.
Как найти такую петлю, мы разберем чуть ниже. Но в целом предугадывать возникновение таких петель не получается. Ее наличие становится видимым , уже когда проявляются признаки зацикливания или когда уже полностью «ложится» вся наша сеть.
Как образуется сетевая петля
Если посмотреть на принцип «сетевой петли», то для большего понимания скажем, что это когда пакет каких-либо данных долго блуждает по одному и тому же маршрутному кругу от коммутатора к коммутатору и никак не может достичь своего конечного получателя. От этого с лучается перегрузка сети и она «ложится» , т ак как становится просто перегруженной IP-пакетами, которые не перестают множит ь ся из-за коммуникации между сетевыми устройствами. Но пакеты не покидают маршрутную сеть, а блуждают внутри сетевой петли, так и образуется сетевой шторм.
Плюс, так как внутри локальной сети присутствует большое количество зацикли в шихся пакетов, то достаточно сильно снижается пропускающая способность всего канала связи. Но это тоже еще не все. Если у вас довольно большая сеть, то могут случиться проблемы и на других участках. Одна немного приятная новость, что возникшее зацикливание не вечно, жизнь самих сетевых пакетов ограничена по времени.
Как определить сетевую петлю по ее признакам
Как найти сетевую петлю в локальной сети
- Первое , что нужно сделать , — это определить локальный участок, где происходит зацикливание. Определить н ет рудно — там возникают проблемы с И нтернетом.
- Подберите любой сниффер и можете его запускать для определения зацикленных устройств.
- Определите сетевые пакеты, создающие шторм , и отфильтруйте их. Найти их будет н ес ложно — их огромное количество и у многих схожий ID IP.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Петля в локальной сети: что такое и как найти
Петля (или кольцо) в локальной сети это ситуация, при которой часть информации от коммутатора не рассылается по компьютерам, а кочует по двум параллельным маршрутам, как бы замыкающимся в кольцо. Данные при этом бесконечно кружатся по этому кольцу, постепенно увеличиваясь в размерах и забивая весь канал.
Петля является крайне неприятным явлением для локальной сети или её отдельного участка и требует немедленного решения. Для большего понимания простейшая схема петли представлена ниже.
С петлей мне пришлось столкнуться в одной средней размеров конторе по долгу службы. Офис там располагался в видавшем виде здании, по-моему, даже частично или полностью деревянном. Сетевое оборудование было соответствующее, поэтому, когда в один не слишком добрый понедельник мне заявили о медленном Интернете, я, поначалу, не придал этому особого значения. Затем отвалились и Интернет, и 1С.
Поняв, что проблема, скорее всего, в неисправности коммутатора или кольце, я отправился в коммутационную. Там меня ждали три неуправляемых D-Link’а (это не оскорбление, а вполне себе термин для коммутатора).
Поначалу я всё же думал на неисправность коммутатора (тем более, что есть у меня субъективное недоверие к D-link). Количество портов трех 24-портовых коммутаторов для небольшого офиса на 10-15 машин было излишним, и оставалось еще от старых-добрых времен, когда компов в сетке было больше. Для вычисления виновника я по очереди выключал коммутаторы, и смотрел как на это отреагирует сеть. После нахождения нужного мне свича, все пользователи были переведены на оставшиеся два коммутатора, а я стал думать как вычислить нужный мне порт, ведь неисправен мог быть не весь коммутатор. Тогда ко мне и закралась мысль о кольце.
Первым делом я стал проверять, не может ли быть так, что один и тот же патч-корд воткнут обоими концами в один свич. Мне повезло, и такой кабель действительно был. Это вполне могло быть «подарком» предыдущего админа, чем-то не сошедшегося с руководством. Во всяком случае, вряд ли бы кто-то полез к свичам случайно.
Если бы кольцо не было таким явным, мне пришлось бы помучиться. Дело в том, что я выключил коммутатор, и повторного появления кольца нужно было бы подождать. Потом пришлось бы доставать из портов патч-корды и смотреть на реакцию сети. В целом, всё равно всё свелось бы к схеме, нарисованной выше, с её сетевыми розетками и патч-панелями.
Итак, несколько советов как вычислить петлю в локальной сети:
- Локализуйте проблему. Падает вся сеть или отдельный участок? Если у одного отдела сеть есть, а у другого нет, то проверяйте коммутатор, раздающий сеть на тот отдел.
- Какой тип коммутатора(-ов) используется? Это может быть управляемый коммутатор или неуправляемый. В проблемном участке может быть и смесь из обоих вариантов. В случае с неуправляемым коммутатором придется вычислять проблемный порт методом научного тыка. В управляемом коммутаторе порты можно закрыть через веб-интерфейс.
- Проверьте кабели. Скорее всего, дело всё-таки в физическом закольцевании сети. Но может «сдуреть» отдельно взятый порт в коммутаторе или сетевой плате компьютера. Редко, но может встретиться ситуация с дублированием функций DHCP-сервера, когда устройство (роутер, коммутатор или компьютер), которое этого делать не должно, раздаёт остальным некорректные настройки сети. В таком случае выключите DHCP-сервер и попробуйте получить адрес с какого-либо компьютера в проблемном участке сети. Если опасения подтвердились — проверяйте устройства на предмет включения функции DHCP-сервера. В первую очередь, конечно, роутеры и коммутаторы.
На этом, пожалуй, всё, что нужно знать о тактике борьбы с петлями в локальных сетях. Напоследок еще можно дать совет — пользуйтесь управляемым оборудованием. Это существенно облегчает труд системного администратора и позволяет решать ряд проблем, вообще не вставая из-за стола.