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;
  • Ну и несколько стандартных библиотек.

Далее все легко и просто. Создаю экземпляр класса pcapy.open_live c выбранным интерфейсом и добавляю к нему фильтр. Создаю первый цикл, который будет периодически отправлять пакет, а внутри него второй, что бы захватывать и обрабатывать вернувшиеся пакеты. Если захваченный пакет идентичен отправленному, то добавляется +1 к счётчику. Если после истечения тайм аута получено больше одной копии пакета, проигрывается звук, а на консоль выводится сообщение о петле.

С получившимся скриптом можно ознакомится далее.
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()


Ссылка на оригинал и исходники
Поделиться публикацией
Комментарии 72
    +3
    Будучи студентом, никогда не думал, что скажу эту фразу — а вывод? Опыт использования? Помогло?
      0
      И сколько времени длится определение петли по сравнению с STP реквестирую. А еще лучше с RSTP.
        0
        timeout = 1

        Столько времени и длится.
          0
          Спасибо. А то я подумал, что
          endTime = time.time() + self.timeout

          как-то связано с временем выполнения.
        0
        Да вот всё про тестировать негде (не случаются петли). На столе проверили, битые порты, петли всех видов и мастей определялись на ура.
        Область применения везде где нужно найти петлю и есть возможность подключится непосредственно в сеть. В сравнении с tcpdump сильно экономит ресурсы головного мозга.
        –11
        Игра — угадай язык программирования. Чур, в тэги не смотреть.
          +10
          Чего Вы? Python не сразу разглядеть?
            0
            А где-то ещё такие конструкции есть, кроме питона?
              +1
              Честно говоря, я не ожидал увидеть питона. Но вот признал его сразу, хоть и не пишу на нём.
              –2
              <hr />
              Но не так уж мало сетей где к одному порту подключена цепочка из 5 — 6 неуправляемых коммутаторов.

              В 21 веке такие сети долго не живут — мультикаст, броадкаст/arp флуд,, торренты убивают такие сети легко и не принужденно. Все клиенты разбегутся по значимым конкурентам типа билайна, интерзета и т.д.
                +1
                За мкадом и кадом жизнь тоже есть.
                  +1
                  Управляемое оборудование которое имеет минимальный функционал стоит на ebay от 20 до 50 баксов, доставка 30. Это в основном 24 порта, а бывает и 48. Так что не надо про МКАД рассказывать — желание сэкономить 3 копейки нельзя оправдать МКАДом
                    +4
                    ебей какой-то, баксы. «Страшно далеки они от народа».
                      0
                      Реальная отмазка бывшего директора: «управляемое оборудование не нужно, бо спи....»
                        +1
                        Отмазка-неотмазка, но ведь реально сопрут. :-) Корбиновскими/Билайновскими DES-3526 еще недавно все рынки были завалены — не знаю как сейчас. Собственно, как только нашли, как у них пароль сбрасывать — сразу и повалили пачки… Потом волна чуть схлынула, но пошла другая тема — те же Корбиновские/Билайновские, но списанные по причине блоков питания (2 конденсатора перепаять — стоимость и время ремонта стремятся к нулю) и продаваемые самими сотрудниками… И это в Москве. Что творится в регионах я вообще боюсь представить…
                          0
                          Там где Я давно работал DES-2108 на дом (саппорт радовался бы на 3-5 домов) хватило бы (3-5 этажей и 3-5 клиентов с линками до 190метров). Настоящая гавносеть, так как самы длиный участок: 7 км и over 50 тупых свичей (общее под 600 шт). Спасали от флуда самые дешевые домашние роутеры на 3-5 домов (в сторону от «магистрали») + VPN.

                          Сеть осенью (грозы) поднималась до 1 месяца :)
                            0
                            Сейчас, я полагаю, это уже неактуально, но тогда я бы вам посоветовал посмотреть в сторону любых коммутаторов на чипах rtl83xx и OpenRRCP. У меня на медной сети с около 3 тыс. клиентов во вполне промышленной эксплуатации даже IPTV мультикастовое работало. И красивая карта была, где домики радостно «горели» зеленым цветом, так что даже в случае чего было сразу ясно, куда идти. :-) Особенно доставлял феерический коммутатор Compex SDS1224 (ныне снятый с производства), который стоил 1100 руб. за 24 порта (16-портовый Компекс стоил 900 рублей или типа того). Длинки со своими ценниками нервно курили в сторонке. ;-)
                    0
                    А какая разница для неуправляемых коммутаторов между броадкастом\мультикастом и юникастом?
                      0
                      Ну про броадкаст я говорил в ключе что никто не сможет быстро найти такого человека на неуправляемом свиче.
                      А про мультикаст — свич 5 портов (типовая ситуация таких сетей), все одновременно включают iptv. Разные каналы. 4-5 мбит на канал, во все порты долбится поток в 4 потока по 20 мбит. Не очень мощные роутеры дохнут. На компе (в зависимости от сетевой карты и процессора) может начатся свистопляска.
                        0
                        Для l2 коммутаторов, я бы сказал. Управляемость дело в общем-то второстепенное.
                          0
                          Да нет, почему, вроде для управляемых коммутаторов IGMP Snooping дело сейчас достаточно распространенное.
                            0
                            Потому что IGMP это L3, а так всё ок.
                              0
                              IGMP — это L3. Я говорил про IGMP Snooping — это L2. Почитайте хотя бы в википедии.
                                0
                                Ну при чём тут википедия. Коммутатор разбирает кадр до заголовка IP? Разбирает. Всё, L3. Почему L2-то.
                                  0
                                  Я специально перечитал про IGMP и не нашел в IGMP-запросах заголовков IP. Поясните?
                                    0
                                    а их там и нет.
                                    tools.ietf.org/html/rfc1112
                                    2я версия. По идее, самая распространенная. На практике — хз.
                                      0
                                      The multicast extensions to a host IP implementation are specified in
                                      terms of the layered model illustrated below. In this model, ICMP
                                      and (for level 2 hosts) IGMP are considered to be implemented within
                                      the IP module, and the mapping of IP addresses to local network
                                      addresses is considered to be the responsibility of local network
                                      modules.
                                        0
                                        И дальше по тексту:

                                        This model is for expository purposes only, and should not
                                        be construed as constraining an actual implementation.

                                        И потом, IGMP и IGMP Snooping — разные протоколы. Никто не спорит с тем, что IGMP — это L3.
                                          0
                                          И что там дальше по тексту? Дальше по тексту говорится что это обобщённая, упрощённая для понимания абстракция, что из этого?
                                          Я в курсе что такое IGMP, IGMP Snooping и прочие вещи. Я не понимаю, как не очевидно то, что в снупинге свитчу приходится раскручивать фрейм до третьего уровня. Или тут тоже возражения? IGMP Snooping работает на втором и третьем уровнях, такое бывает.
                                          Изначально мне резануло упоминание «управляемых коммутаторов», которые вообще ни к селу ни к городу в контексте бродкастов/юникастов, совершенно технически безграмотная фраза.
                                            0
                                            Изначально мне резануло упоминание «управляемых коммутаторов»
                                            Изначально не были упомянуты управляемые коммутаторы вообще.

                                            Изначально мне резануло упоминание «управляемых коммутаторов», которые вообще ни к селу ни к городу в контексте бродкастов/юникастов, совершенно технически безграмотная фраза.
                                            Докажете? Я вот считаю, что юникасты на управляемых и неуправляемых коммутаторах обрабатываются по-разному.

                                            Я в любом случае прошу Вас привести цитаты конкретные. Нигде в стандарте не написано, что снупинг работает на 3-ем уровне, и везде в литературе я встречал только 2-й. Так что я солидарен с фразой из английской википедии:
                                            Essentially, IGMP snooping is a layer 2 optimization for the layer 3 IGMP.
                                              0
                                              Господь с вами, почитайте что такое transparent bridge. Если не включать всякие разные навороты, типа mac acl, unicast flooding control и прочее, прочее, что умеют современные управляемые свитчи, юникаст трафик умные и тупые коммутаторы передают абсолютно одинаково.

                                              далее про мультикаст. клиент посылает ip пакет на мультикастовый адрес 224.0.0.22 с типом протокола верхнего уровня igmp, где уже в igmp заголовке написано на какую группу клиент хочет подписаться. Свитч увы должен этот пакет вскрыть аж до igmp заголовка, чтобы узнать в какую мультикаст группу стоит отнести данный порт. Собственно называть вы это можете хоть технологией третьего уровня, хоть технологией второго уровня, но технически прав allarm
                                                0
                                                Да, а если вообще не включать устройства, то они абсолютно одинаковые. О чем речь? Еще можно вспомнить про VLAN, и тогда пакеты, в том числе и бродкастовые, будут обрабатываться совершенно по-разному.

                                                Вторая часть уже разъяснена. За одним только исключением — коммутатор остается L2.

                                              0
                                              И зачем вообще тогда снупинг, почему нельзя обрабатывать тогда тупо IGMP, коль уровень третий?
                                                0
                                                Коммутатор и обрабатывает IGMP. Мониторит проходящие от клиентов к querier'ам сообщения и в соответствии с ними действует, чтобы не грузить сеть бродкастом. Именно этот процесс и называется снупингом. :-)
                                                  0
                                                  Ужас. Чем там посыпать голову нынче модно?
                                              +3
                                              Вы все-таки не правы. IGMP snooping — это вообще не протокол, а просто технология коммутации. И таки да — она может быть только L3, т.к., как вам сказали выше, коммутатор разбирает проходящие пакеты вплоть до тела самого IGMP, который действительно инкапсулирован внутрь IP (http://tools.ietf.org/html/rfc3376#section-4). А разбирает он их в любом случае, т.к. ему нужно определить, к какой группе подключается клиент, чтобы именно эту группу слать ему на порт (а потом отслеживает репорты от клиента, чтобы когда их не будет и пройдет таймаут — перестать слать эту группу).
                                              Вся прелесть в том, что поддержка коммутатором IGMP snooping совершенно не эквивалентна поддержке им самого IGMP. IGMP — это протокол в общем-то маршрутизации. Им пользуются клиенты, подключающиеся к группам, и маршрутизаторы (Querier'ы в терминологии IGMP), которые эти группы им отдают. Коммутаторы уровня распределения, через которые идет сигнал от маршрутизатора до клиента, в обмене сообщениями IGMP не участвуют. Максимум, что они делают — фильтруют сообщения, что нужно делать, если используется IGMP v3 (а то один отключившийся от группы клиент при включенном на коммутаторе снупинге всех остальных клиентов этого коммутатора тоже от группы отключит).
                                                0
                                                Да, IGMP Snooping это не протокол, моя вина. Это стандарт. Стандарт для L2 коммутаторов, добавляющий хук для дружбы с IGMP. Так что, я думаю, вообще некорректно относить его к какому-либо уровню.
                                          0
                                          IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2.

                                          RFC 3376, Internet Group Management Protocol, Version 3

                                          А по поводу снупинга — как иначе по вашему свич понимает, что это IGMP-запрос, не добравшись до его уровня инкапсуляции?
                                            +2
                                            Термин «L2-свич» обычно означает свич, который принимает решение о выборе интерфейса назначения исходя из L2 (MAC) адреса. То, что для каких-то других функций он может смотреть и в L3 (и иногда даже дальше), не делает его L3-свичом.
                                              0
                                              Ну еть еще некий вид L3 Basic
                                          0
                                          Сможете объяснить тогда как работает ip acl на реаальном l2 коммутаторе?
                                            –2
                                            А это не философские ли споры пошли? По мне так если свитч умеет работать с ip то это L3 свитч.
                                              0
                                              Так Вы изначально не говорите так что мол l3 и баста. Не начинайте на it ресурсы такие споры.
                                                0
                                                Если свитч умеет работать с л3 то это л3 свитч и баста, ок.
                                                  +3
                                                  На управляемых свичах есть телнет, значит они — L7-свичи?
                                                    0
                                                    Многие и вебсерверы держат, кстати.
                                                    +4
                                                    Вы не правы. Вспомним о том, что «свич» — это коммутатор. :-) Уровень коммутатора определяется по тому, какие пакеты он может коммутировать. Если он может коммутировать только L2 пакеты — значит это L2 коммутатор/свич. Если может коммутировать L3 пакеты (выражаясь бытовым языком — выступать в качестве IP-маршрутизатора, хотя так говорить и безграмотно) — значит это L3 коммутатор/свич. :-)
                                                    Наличие в L2 коммутаторе функционала по работе с содержимым пакетов дальше 2 уровня (ACL, фильтры всякие, снупинги и т.п.) совершенно не делает его L3 коммутатором. :-) По маркетинговым соображениям такие коммутаторы называют L2+ и хотя соображения явно маркетинговые, лучшей альтернативы, вроде, никто не придумал. :-)
                                              +1
                                              Насколько мне известно, L3 означает, что коммутатор обладает базовыми функциями маршрутизации. Т.е. он может оперировать не только фреймами, но и IP-пакетами (ну или другими пакетами уровня 3).
                                          0
                                          Именно. И для l2 управляемость дело как раз таки одно из первостепенных.
                                          1. Port security
                                          2. Acl
                                          3. Igmp snooping
                                          4. Диагностика неисправностей. Начиная от проблем с кабелем заканчивая просто посмотреть маки на порту.
                                          5. Ну и конечно же мониторинг.
                                          Я может что то забыл, но без этих вещей я бы точно не взял l2 коммутатор. Не добавляю сюда loopback detection ибо фича за которую надо переплачивать. А начали мы разговор с МКАД.
                                            0
                                            К вашему списку я бы добавил VLAN и тот же самый RSTP. Если денег хватает, то с кольцевой топологией.

                                            PS. Я вот лично не начинал разговор про МКАД и никак в нем не участвовал.
                                              +1
                                              Ну вланы само собой. Я таких управляемых девайсов то в последнее время и не вижу.
                                              А вот rstp — это зависит от топологии.
                                              +1
                                              loopback detection есть на многих современных коммутаторах, это не порт 10gigabit, при чем тут переплата?
                                        +1
                                        Да нормально работают. Я не к тому, что ставить неуправляхи это хорошо, но такие цепочки живут и нельзя сказать чтобы часто что-то виснет.
                                          0
                                          Живут, и уже довольно долго. Естественно, это не радует, но приходится работать с чем есть. Да и преувеличиваете Вы, по-моему, насчёт убийственного влияния «мультикаст, броадкаст/arp флуд,, торренты» на жизнеспособность неуправляемого сегмента. По крайней мере, я сам не могу сказать, что я ночами не сплю из-за того, что подключен в неуправляемое оборудование. =)
                                          0
                                          семейство протоколов stp позволяет специально строить кольцевую топологию (для повышения отказоустойчивости и надёжности)

                                          Какую какую топологию? И это — в разделе матчасть?
                                            0
                                            Радья Перлман явно перевернулся и не раз :)
                                              +1
                                              Учитывая, что она — женщина, Ваш комментарий добавил еще виток. =)
                                                0
                                                Это еще раз доказывает, что надо проверять, что дописывает донабор на телефоне :)
                                              0
                                              Может имелись в виду альтернативные порты в RSTP?
                                                0
                                                Альтернативные порты и связи на них не являются частью активной топологии. А если бы являлись, топология была бы решеткой, но не кольцом. Кольцевых топологий я знаю много, и ®STP не является одним из них.
                                                  0
                                                  Я понимаю. Я пытался понять, что хотел сказать автор, как говорится.
                                              +1
                                              Основной задачей STP является приведение сети Ethernet с множественными связями к древовидной топологии, исключающей циклы пакетов. © Wikipedia Уж простите.
                                                0
                                                Только зачем все это? кто-то строит сети на тупых свитчах и роутит потом это писюками?
                                                  0
                                                  Была ситуация, когда медные линки заменялись на оптические и коммутаторы даже виду не подали по началу. Проблема началась когда при построении кольца я отключил RSTP на всех портах, на которых он был не нужен. После этого появились явные признаки закольцовки. В конце концов нашли причину. Если бы я не трогал STP, так и не узнал бы о том, что техники забыли отключить медную «витуху».
                                                    0
                                                    DES-3016 (глинк) вообще не может определить петлю если просто соединить два его порта.


                                                    А это вполне понятно. В DLink'ах loopdetect реализован по принципу, что если кадры ethernet, ушедшие из порта, в него же возвращаются, то петля есть. Например, если подключить «тупой» свитч (1008D, 1016D) в один из портов управляемого коммутатора и уже на нём замкнуть пару других портов, то управляемый сразу же определит петлю. А передача между двумя портами управляемого коммутатора dlink не будет обнаружена.
                                                      0
                                                      Таки смотря на каком. Как я помню, у них это как отдельная функция реализована. Loopdetect обычный — как элемент RSTP, а соединение своих же портов — совсем-совсем отдельно и не у всех. Но есть! И мне даже пригодилось один раз в захламленной серверной, где было непонятно, какие провода из свича куда идут! ;-)
                                                        0
                                                        Такое должен определять stp со включенным bpduguard
                                                          0
                                                          bpduguard защищает от другого. А вот LBD встроенный в DLink'овский STP как раз отсекает закольцовки между портами. но с ним нужно быть осторожным.
                                                        +2
                                                        Вопрос к автору, не силен в питоне, но насколько я понял ваш скрипт определяет просто наличие петли в сети?
                                                        В чем тогда его практический смысл? узнать что петля есть — это конечно хорошо, но важно ее найти и устранить. а как ваш скрипт помогает в этом деле, я пока не понимаю…
                                                          0
                                                          Устраняет петлю в сети обычно пара рук и ног с клещами, витой парой, тестером и запасным коммутатором.
                                                          +2
                                                          Кстати вот еще метод (правда, довольно индусский) определения петель. Я столкнулся с тем, что в сегменте, в котором есть закольцовки или коммутаторы-зомби, очень плохо работает PPPoE, возникает ошибка «линия занята». Возникает она по понятной причине — фрейм PADI приходит на сервер два раза, для первого он пытается инициировать сессию, для второго тут же отказывает. Получается что клиенту приходит и приём и отказ одновременно.

                                                          Так вот, о методе. PPPoE-сервер у меня на Linux. В опциях включено журналирование пакетов с некорректным адресом источника и назначения (martian source / destination). Если закольцовка есть — в логах начинают бешеными темпами появляться сообщения о том, что в VLAN'е, принадлежащем неисправному сегменту, обнаружены пакеты с «марсианскими» адресами источника. Скрипт, каждые пять минут запускаемый кроном, проверяет нет ли в последних строчках лога таких сообщений, если есть — сигнализирует. Плюс к этому — срабатывание loopdetect можно фиксировать по icmp trap.
                                                            0
                                                            SNMP trap, прошу прощения.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое