Як я можу діагностувати мостиковий цикл (Ethernet)?

Зважаючи на те, що розповсюджене дерево не вийшло (або у вас немає дерева, що охоплює), і отримати цикл Ethernet, який найкращий спосіб діагностувати, де проблема?

Який перемикач ?, який кабель? і так далі.

Добре, тож припустимо, що у вас є така топологія, як:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Чомусь є мостиковий цикл, STP вимкнено або хтось застосував фільтр у неправильному місці чи іншому.

PC A хоче спілкуватися з PC B. Спочатку ARP для MAC ПК B, адреса призначення - це трансляція з MAC ffff.ffff.ffff. Таким чином, кадр переходить до SW1 та SW3. MAC SRC є PC A. SW1 тоді затоплює кадр у напрямку SW3, а SW3 затопить кадр, що йде від SW2 до SW1.

SW1 та SW3 засвоїли MAC ПК A, коли перший кадр увійшов. Коли другий приходить з протилежного напрямку, він повинен його вивчити. Оскільки ці події відбуваються настільки швидко і неодноразово, ви побачите повідомлення журналу, що скаржаться на плескання MAC. Щось на кшталт "MAC FLAP 0000.0000.0001 махає між Gi0 / 24 та Gi0 / 23". Це хороший знак того, що у вас є петля.

Що ви могли зробити тоді, це спробувати простежити цей MAC. Спробуйте заглянути в кеш-пам'ять ARP пристрою в тій самій підмережі і побачити, яку IP-адресу має цей пристрій. Тож за допомогою MAC ви можете спробувати простежити його за допомогою sh mac-address-table або IP-адреси, можливо, у вас є список з усіма IP-адресами та де вони підключені.

Якщо хост отримує IP-адресу від DHCP-сервера, ви також можете спробувати там, звідки хост походить. Якщо у вас включений варіант 82, це буде чудовою допомогою.

Іншими ознаками є те, що CLI буде дуже млявим. Навантаження процесора буде дуже великою. Перемикачі роблять майже все в ASIC, тому якщо комутатор має завантаження процесора понад 50%, це, мабуть, не добре. Ви повинні впровадити моніторинг SNMP та стежити за високим завантаженням процесора. Також шукайте закриті повідомлення MAC. Якщо у вимикачів є петля, світлодіоди, ймовірно, блимають, як божевільні.

Що можна зробити для захисту від циклів:

• Увімкнути STP! (да)
• SNMP-моніторинг завантаження процесора
• Увімкніть ловушки SNMP для певних подій, таких як зміни топології STP
• Увімкніть управління штормом у портах, щоб обмежити мовлення
• Не накладайте занадто багато своїх VLAN в топології L2
• Увімкніть безпеку порту та обмежте кількість MAC-адрес на порт
• Увімкніть Option82, якщо ви запускаєте DHCP

Один з моїх користувачів нещодавно запозичив перемикач робочого столу з чийогось столу. Повернувши комутатор, вони підключили всі вільні кінці Ethernet, які були поруч. Один з цих кабелів пішов до мережі, а інший - два кінці того ж кабелю. Перемикач робочого столу був підключений до мережі, а також підключений до себе. У комутатора не було STP, тому трансляції, що надходили з мережі, переходили б на інший кабель в обох напрямках. Звичайно, щоразу, коли трансляція надходить на петельні порти, вона повторюється назад у мережу. Це призвело до того, що HSRP абсолютно збожеволів, і - через погану конструкцію - це також призвело до збоїв у примиканні OSPF по всьому кампусу.

Першою вказівкою на проблему став macflap, пересланий на мій електронний лист. Це негайно призвело нас до правильної шафи для електропроводки. Звідти це був процес усунення на основі світлодіодів портів, pps інтерфейсів та журналів. Потрібно сказати, що я з часу перестановки всього кампусу. Найкращий запобіжний захід - це, мабуть, bpduguard. З тих пір я розгорнув цю функцію, і це було досить просто. Отримати цей помилковий syslog у своєму електронному листі - це не що інше, як блаженство.

На більшості обладнання процесор спрацьовує до 100%, і єдине, що ви можете зробити - це порушити зайві фізичні з'єднання. Як тільки процесор заспокоїться, ви можете підключити посилання одне за одним і побачити, яке з них викликає цикл.

Для великого шасі (як 6500) мені довелося витягнути всі леза і підключити їх по черзі. Одного разу я зрозумів, яке лезо, то мені довелося витягнути всі окремі ланки (16 ГБІК) і вкласти їх також по одному. Ніколи не весело.

Деяке більш сучасне обладнання має захищений процесор, який повинен полегшити роботу - ви все ще можете взаємодіяти з коробкою. У цей момент стає можливим перегляд лічильників трафіку і таких, щоб визначити несправність посилання.

Нещодавно я почав працювати в компанії, де вони використовують ліміти мовлення на кожному порту. Якщо порт пропускає> 5% його ємності під час трансляції, перемикач переводить його в ПОМОГУ.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Це було рятівним життям, коли одна група прагне підключити пристрої, які з'єднують бездротові мережі в локальну мережу.

Хоча для вашого актуального питання, я завжди вважав, що це посібник.

для IOS:

Ймовірно, у вас будуть MAC-адреси, що перекидаються між портами .. шукайте MAC_MOVE_NOTIFICATION(або подібні) помилки в:

sh logg

Тепер, щоб знайти порт:

sh int g0/1 controller

шукати поза звичайними Multicastта Broadcastчислами. Будь-які зіткнення - поганий знак.

І останнє, але не менш важливе значення, ви не можете увійти, оскільки процесор pwned :)

sh proc cpu

Як тут робиться вимикач? Якщо це лише комутатор L2, ви нічого не бажаєте вище ~ 10%

У випадку, якщо ви не керовані, або еквівалентність некерованих (відсутність даних про вхід або знання операційної системи комутатора тощо), комутаторів та мостового циклу, я описую, як би я пішов про пошук циклу вручну. Це також стосується основної основи початкового питання "у вас немає STP".

Основний алгоритм для виявлення несправностей у цьому циклі схожий на STP, за винятком того, що ви не маєте доступу до надсилання BPDU з ідентифікаторами порту.

• Спочатку підключіть пристрій, здатний скинути / понюхати пакет, до порту в одному з комутаторів. Цей пристрій став кореневим пристроєм вашого дерева.
  • Якщо вам доведеться знаходити несправності в декількох місцях, наприклад, над «кампусом» або подібним, ви можете виграти, маючи можливість віддалено увійти з портативним клієнтом ssh на машину демпінгу пакетів.
    • Я особисто використовував мій ноутбук Linux з підключенням до Інтернету з tcpdump на екрані і впадаю в нього з, наприклад, ipad або телефону.
  • Якщо ви не можете ввійти в систему дистанційно, скористайтеся другом для візуального моніторингу tcpdump, який, ймовірно, затоплює зі швидкістю зв'язку, що дозволяє легко помітити різницю, коли шлях до пристрою джерела циклу відключається.
• Далі вам доведеться по суті відтворити дерево, починаючи з кореневого перемикача.
  1. А оскільки у вас може бути сценарій, коли у вашому кореневому пристрої подається кілька посилань циклічного зв’язку, потрібно почати з одночасного видалення всіх підключених портів.
  2. Повторно підключіть порти один за одним, і якщо в будь-який момент пакетний пакет знову з’явиться, виконайте цей порт до підключеного перемикача на іншому кінці.
  3. Повторіть крок 1, поки ви не знайдете петельний порт (и) і не зможете повторити його вниз в дереві вручну.
  4. Вирішивши ситуацію циклу в цьому комутаторі, поверніться до перемикача вище в дереві та відновіть крок 2. Ця рекурсія триває весь шлях назад, поки фінальний кабель не буде підключений повторно у вашому кореневому комутаторі.

Це повністю вичерпний ручний пошук петельних портів.

Як правило, буде просто одна пара портів, які є циклами, що означає вичерпний і безпечний пошук, спочатку видаляючи всі підключені (посилання) порти, а потім повторно з'єднуючи їх один за одним, не потрібно. Якщо лише одна пара портів по всьому «дереву» є петлею, її можна знайти, просто відключивши один порт за один раз.

Тим не менш, загальний, "недобросовісний" метод або алгоритм стає тим, що я описав вище.

Ой. Але гаразд, я можу придумати два шляхи, щоб я пішов у цьому ...

Eyeball it: Якщо в комутаторах є індикатори портів, ви повинні мати можливість очного яблука, які порти є найактивнішими. Це ті, хто повинен почати дивитися спочатку. Сподіваємось, кабелі позначені міткою, щоб ви могли шукати низько висячі плоди пошуку двох зайнятих портів на двох комутаторах одним і тим же кабелем.

Моніторинг SNMP: Якщо у вас є статистика використання SNMP (або подібної), шукайте найзайнятіший комутатор і найзайнятіші порти. Потім переходьте до кабелів.

... якщо у вас немає маркованих кабелів, починайте відстежувати та маркувати як частину перевірки найзайнятіших портів.

Я збираюся відповісти на це запитання, виходячи з розуміння того, що для доменного рівня 2, про який йдеться, повне вимкнення, і що у вас немає доступу до управління, оскільки всі процесори прив'язані.

Найкращий спосіб усунення мостової петлі - почати відключення підключень до того часу, поки вона не згасне. Скажімо, у вас є стандартний комутований шар доступу з усіма перемикачами доступу, що з'єднуються в пару комутаторів розподілу. Перейдіть до першого вимикача доступу та відключіть підключення до мережі, якщо світлодіодні індикатори для комутаторів перестають працювати, це не той перемикач, підключіть його назад та перейдіть до наступного. Повторюйте, поки не дістанетесь до вимикача, де ви відключили підключення до лінійки та світлодіоди продовжують швидко блимати, це ваш перемикач із циклом.

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

Якщо чесно, якщо ви віддалено підключились (або за допомогою консольного кабелю) до пристрою, ви помітите його дуже мляво, буде настання затримки, коли ви будете набирати літери, що надходять на CLI.

Якщо його комутатор Cisco, 2 прості переглядати статистику інтерфейсу, він буде постійно користуватися 100% (або 255/255). У мої роки роботи з комутаторами я ще не бачив, як порт легітимно вражав 100% використання. Окрім цього, перевірте використання процесора (як правило, "показати історію процесора процесора"), петельні інтерфейси, як правило, досить сильно впливають на ваш процесор, якщо ви не працюєте в комутаторі високого рівня.

STP дійсно повинен бути включений, хоча!

У мене ця проблема виникала в мережі на іншому кінці США, і мені довелося віддалено допомагати аналітикам рівня першого рівня по телефону та моїм посиланням на їхній сайт. Питання ускладнилося ще й тим, що у них було кілька марок комутаторів, які вони впродовж багатьох років повільно додавали до мережі. Коли вони переїхали в офіс, вони відзначили, куди йде кожен порт, потім повторно приєднали все так само в новому офісі і почали все. Зайве говорити, що кілька комутаторів, які мали працююче розкидне дерево, не збігалися однаково, і у них були всі види циклів і проблем. На той момент, коли я робив виправлення всього, було виявлено, що не менше трьох некерованих комутаторів були з'єднані в петлі з іншою частиною інфраструктури.

Спосіб відстеження кожного з некерованих комутаторів був за допомогою інструменту під назвою nedi (для перемикачів, якими вдалося керувати, я включив lldp / cdp). Я вперше створив карти з неді. Тоді в районах, де на карті показано з'єднання від одного комутатора до іншого, а потім знову до того ж комутатора, я змусив мережевого техніка на сайті простежити лінію вручну. Я або вручну відключив інтерфейси, пов'язані з циклом, або змусив особу на місці відключити кабелі. Врешті-решт мені вдалося змусити мережу працювати як слід, незважаючи на всі шалені вимикачі бренда.

Одне, що тут можна зробити, - це побачити, які машини підключені до комутатора за допомогою команд show cdp neighborабо show lldp neighbor.

Якщо команда захисту БДДУ не використовується, а хтось підключає шахрайський перемикач з нижчим пріоритетом (або старішою mac-адресою), новий пристрій узгодить як кореневе дерево Spanning Tree, що, безумовно, спричинить проблеми.

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

Визначення циклу дійсно залежить від марки комутатора, який у вас є. Наприклад, на комутаторі Extreme я можу запустити elrp-клієнт у VLAN, і комутатор в основному надсилатиме кадр широкомовної передачі на всі порти для цієї VLAN і бачить, чи повертається він будь-яким з них, якщо так, то він підказує мені, який порт (и) кадр отримано назад, тим самим розкриваючи кандидатуру циклу.

У Cisco ви можете ввімкнути управління штормом, який є трохи більш тупим інструментом, оскільки він в основному блокує порт протягом періоду часу, поки статус не очиститься (або ви очистите стан, який не можна помилити) - загалом кажучи, цей тип Зрештою, це актуально лише тоді, коли ви використовуєте комутатори Cisco у змішаній топології пристроїв, які не роблять ані співоче дерево, ані передніми BPDU.

Без сумніву, найшвидший підхід, який я знайшов, - це моніторинг частоти пакетів / сек інтерфейсів. Швидкий показ інтерфейсів із відповідним фільтром CLI відображатиме список кожного інтерфейсу та швидкість пакету / сек. Щоб знайти джерело циклу, шукайте єдиний інтерфейс з шалено високою швидкістю INPUT пакету / сек. У типовому середовищі підприємства, з типовими профілями використання, він працює щоразу без збоїв. На 6500 з безліччю інтерфейсів не потрібно багато часу, щоб помітити джерело ...

Під час циклу велика кількість трансляційного трафіку (наприклад, ARP Request) на кінцевій станції також може збільшити навантаження на процесор (наприклад, якщо ви використовуєте дешеву карту realtek 100Mbit / s, яка обчислює контрольну суму на процесорі). Як фізично можливо знайти цикл, якщо кабель відключений, посилання втрачається негайно на 2 порти.