ARP транслює мережу затоплення та високе використання процесора

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

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

Оригінальний випуск розміщено в Інтернет-спільноті INE

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

Факти:

• Ми використовуємо 3750x вимикачі, 4 в одній стеці. Версія 15.0 (1) SE3. Cisco TAC не підтверджує жодних відомих проблем для високих помилок CPU або ARP для цієї конкретної версії.
• Немає підключених концентраторів / некерованих комутаторів
• Перезавантажений стек Core
• У нас немає маршруту за замовчуванням "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Використання OSPF для маршрутизації.
• Ми бачимо великі пакети широкомовної передачі від VLAN 1, VLAN 1, які використовуються для настільних пристроїв. Ми використовуємо 192.168.0.0/20
• Cisco TAC сказав, що вони не бачать нічого поганого у використанні / 20, інакше у нас буде великий домен широкомовної передачі, але він все одно повинен функціонувати.
• Wi-Fi, управління, принтери тощо - всі на різних VLAN
• Розташоване дерево було перевірено кваліфікованими особами Cisco TAC та CCNP / CCIE. Ми відключаємо всі зайві посилання.
• Конфігурація на ядрі була перевірена Cisco TAC.
• Для більшості комутаторів у нас встановлений за замовчуванням тайм-аут ARP.
• Ми не реалізуємо Q & Q.
• Не додано нових комутаторів (принаймні жодних, про яких ми знаємо)
• Неможливо використовувати динамічну перевірку арп на крайових комутаторах, оскільки це 2950
• Ми використовували шоу-інтерфейси | inc line | трансляція, щоб визначити, звідки велика кількість трансляцій, що надходять, однак як Cisco TAC, так і два інших інженери (CCNP & CCIE) підтвердили, що це нормальна поведінка через те, що відбувається в мережі (як і у великій кількості закритих маків викликаючи більшу трансляцію). Ми переконалися, що STP справно працює на крайових вимикачах.

Симптоми в мережі та комутаторах:

• Велика кількість кришок MAC
• Високе використання процесора для процесу введення ARP
• Величезна кількість пакетів ARP, швидко зростаючих і помітних
• Wiresharks показує, що 100-ті комп'ютери затоплюють мережу ARP Broadcast
• Для тестових цілей ми поставили приблизно 80 настільних машин різної vlan, однак ми протестували це і не бачили різниці на високому процесорі або arp
• Запускав різні AV / шкідливі / шпигунські програми, але вірусів у мережі не було.
• sh-таблиця адресних таблиць mac, показує нам приблизно 750 різних мак-адрес, як очікується, на vlan 1.

#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri

• Ran show mac-таблиця адрес на різних комутаторах та самому ядрі (на ядрі, наприклад, підключений безпосередньо на робочому столі, на моєму робочому столі), і ми можемо бачити, як декілька різних MAC-апаратних адрес зареєстровані в інтерфейсі, хоча цей інтерфейс має до цього приєднано лише один комп’ютер:

 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3

• показати використання платформи Tcam

 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

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

Оновлення

Дякую @MikePennington та @RickyBeam за детальну відповідь. Я спробую відповісти, що можу.

• Як згадувалося, 192.168.0.0/20 - це спадковий безлад. Однак ми маємо намір розділити це в майбутньому, але, на жаль, це питання виникло раніше, ніж ми могли це зробити. Я особисто також погоджуюся з більшістю, завдяки чому домен широкомовного телебачення є занадто великим.
• Використання Arpwatch - це, безумовно, щось, що ми можемо спробувати, але я підозрюю, що кілька портів доступу реєструють мак-адресу, навіть якщо вона не належить до цього порту, висновок arpwatch може бути не корисним.
• Я повністю погоджуюся з тим, що не буду на 100% впевнений у знаходженні всіх зайвих посилань та невідомих комутаторів у мережі, але як найкраще ми знаходимо, це так, поки ми не знайдемо подальших доказів.
• Безпека порту була розглянута, на жаль, керівництво вирішило не використовувати це з різних причин. Загальною причиною є те, що ми постійно переміщуємо комп’ютери (середовище коледжу).
• Ми використовували портфайн spanning-tree разом із спільно з bpduguard spanning-tree на всіх портах доступу (настільних машинах).
• Наразі ми не використовуємо непереговори про перемикання на порту доступу, але ми не отримуємо жодної скакальної атаки Влана, що підстрибує через декількох владів.
• Дасть сповіщення про таблицю mac-address і перегляне, чи зможемо ми знайти якісь шаблони.

"Оскільки ви отримуєте велику кількість закриттів MAC між комутаційними портами, важко знайти, де порушники (припустимо, ви знайдете дві-три мак-адреси, які надсилають безліч арп., Але мак-адреси вихідних файлів не змінюються між портами."

• Ми почали з цього, вибрали будь-які клаптики MAC і продовжили свій шлях через усі основні перемикання на розподіл до комутатора доступу, але те, що ми знайшли, знову-таки, інтерфейс порту доступу навішував декілька mac-адрес, отже, мак-клапті; тому назад до квадратного.
• Контроль над штормом - це те, що ми врахували, але боїмося, що деякі законні пакети будуть відкинуті, що спричинить подальшу проблему.
• Потрійно перевірить конфігурацію VMHost.
• @ytti, незрозумілі MAC-адреси стоять за багатьма портами доступу, а не окремими особами. На цих інтерфейсах не знайдено циклів. MAC-адреси існують і в інших інтерфейсах, що пояснювало б велику кількість закритих MAC
• @RickyBeam я згоден з тим, чому хости надсилають стільки запитів ARP; це одне з дивовижних питань. Бездротовий міст Rouge - цікавий, про який я не замислювався, наскільки ми знаємо, бездротовий зв’язок є на різних VLAN; але шахрай, очевидно, означає, що він цілком може бути на VLAN1.
• @ RickyBeam, я не хочу дуже відключати мережу від мережі, оскільки це спричинить величезну кількість простоїв. Однак саме тут він може просто заголовок. У нас є сервери Linux, але не більше 3-х.
• @ RickyBeam, чи можете ви пояснити зондування DHCP-сервера?

Ми (Cisco TAC, CCIEs, CCNP) в усьому світі погоджуємось, що це не конфігурація комутатора, а хост / пристрій викликає проблему.

Вирішено.

Проблема пов'язана з SCCM 2012 SP1, службою під назвою: ConfigMrg Wake-Up Proxy . Ця функція не існує в SCCM 2012 RTM.

Протягом 4 годин після вимкнення цього правила в політиці ми спостерігали постійне падіння використання процесора. На той час, коли минуло 4 години, використання ARP становило лише 1-2%!

Підсумовуючи це, ця послуга робить підробку MAC-адреси! Не можу повірити, скільки хаосу це спричинило.

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

Для всіх, хто цікавиться, нижче наведено технічні деталі.

Конфігураційний менеджер підтримує дві технології пробудження в локальній мережі (LAN) для пробудження комп'ютерів у режимі сну, коли потрібно встановити необхідне програмне забезпечення, наприклад оновлення програм та додатки: традиційні пакети пробудження та команди включення AMT.

Починаючи з Configuration Manager SP1, ви можете доповнити традиційний метод пакету пробудження, використовуючи налаштування клієнта проксі-проксі. Проксі-сервер пробудження використовує протокол "одноранговий" і вибрані комп'ютери, щоб перевірити, чи не бувають інші комп'ютери в підмережі, і, якщо потрібно, розбудити їх. Коли веб-сайт налаштований на Wake On LAN, а клієнти налаштовані на проксі-будильник, процес працює наступним чином:

1. Комп’ютери, у яких встановлений клієнт Configuration Manager SP1 і не спить у підмережі, перевіряють, чи не працюють інші комп'ютери в підмережі. Вони роблять це, надсилаючи один одному команду ping TCP / IP кожні 5 секунд.

2. Якщо відповіді від інших комп’ютерів немає, вони вважаються сплячими. Прокинуті комп’ютери стають менеджерами для підмережі.

3. Оскільки можливо, що комп'ютер може не реагувати через іншу причину, ніж він спить (наприклад, він вимкнений, видалений з мережі або налаштування клієнта пробудження проксі вже не застосовується), комп'ютери є щодня надсилав розсилку за 14:00 за місцевим часом. Комп'ютери, які не реагують, більше не вважатимуть, що вони сплять, і їх не буде пробуджено проксі-сервером.

Для підтримки проксі-пристрою для кожної підмережі повинно бути не менше трьох комп'ютерів. Для цього три комп’ютери недетерміновано обираються комп'ютерами-опікунами для підмережі. Це означає, що вони залишаються неспаними, незважаючи на будь-яку налаштовану політику живлення щодо сну або в сплячку після періоду бездіяльності. Комп'ютери Guardian вшановують відключення чи перезапуск команд, наприклад, в результаті завдань з технічного обслуговування. Якщо це трапиться, решта комп'ютерів-опікунів розбуджують інший комп'ютер у підмережі, щоб у підмережі продовжували працювати три комп'ютери-опікуни.

Комп'ютерні менеджери просять мережевий комутатор перенаправити мережевий трафік для сплячих комп'ютерів на себе.

Перенаправлення досягається керуючим комп'ютером, що транслює кадр Ethernet, який використовує MAC-адресу сплячого комп'ютера як адресу джерела. Це змушує мережевий комутатор вести себе так, ніби сплячий комп'ютер перемістився на той самий порт, на якому ввімкнено керуючий комп'ютер. Комп'ютер-менеджер також надсилає пакети ARP для сплячих комп'ютерів, щоб зберегти запис свіжим у кеш-пам'яті ARP. Комп'ютер-менеджер також буде відповідати на запити ARP від ​​імені сплячого комп'ютера та відповідати MAC-адресою сплячого комп'ютера.

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

4. Коли комп'ютер менеджера бачить новий запит на підключення TCP для сплячого комп'ютера, і запит переходить до порту, який сплячий комп'ютер прослуховував, перш ніж він перейшов у сон, комп'ютер менеджера надсилає будильник на сплячий комп'ютер, а потім зупиняє перенаправлення трафіку для цього комп’ютера.

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

Посилання: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

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

ARP / Трансляція шторму

• Ми бачимо великі пакети широкомовної передачі від VLAN 1, VLAN 1, які використовуються для настільних пристроїв. Ми використовуємо 192.168.0.0/20 ...
• Wiresharks показує, що 100-ті комп'ютери затоплюють мережу ARP Broadcast ...

Ваш процес введення ARP високий, що означає, що комутатор витрачає багато часу на обробку ARP. Однією з дуже поширених причин затоплення ARP є петля між вашими перемикачами. Якщо у вас є петля, ви також можете отримати мак-лоскути, про які ви згадали вище. Інші можливі причини повеней ARP:

• Неправильні налаштування IP-адреси
• Атака шару2, наприклад, arp spoofing

Спочатку усуньте можливість неправильних конфігурацій або нападу шару2, згаданого вище. Найпростіший спосіб зробити це за допомогою arpwatch на машині Linux (навіть якщо вам доведеться використовувати livecd на ноутбуці). Якщо у вас є помилка конфігурації або атаки layer2, то arpwatch передає вам подібні повідомлення в syslog, в яких перераховані мак-адреси, які ведуть боротьбу за тією ж IP-адресою ...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)

Коли ви бачите "шльопанці", вам слід відстежити джерело адрес mac і з'ясувати, чому вони борються за один і той же IP.

• Велика кількість кришок MAC
• Розташоване дерево було перевірено кваліфікованими особами Cisco TAC та CCNP / CCIE. Ми відключаємо всі зайві посилання.

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

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

Найпростіший спосіб уповільнити mac-ходи - за допомогою port-security. На кожному комутаторі доступу в Vlan 1, який підключений до одного ПК (без комутатора нижче), налаштуйте наступні команди рівня інтерфейсу на своїх перемикачах Cisco ...

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

У більшості випадків затоплення mac / ARP, застосування цієї конфігурації до всіх ваших портів крайових комутаторів (особливо будь-яких з portfast) поверне вас до нормального стану, оскільки конфігурація відключить будь-який порт, що перевищує три mac-адреси, та відключить таємно петельний порт-порт. Три маки на порт - це число, яке добре працює в моєму середовищі робочого столу, але ви можете підняти його до 10 і, ймовірно, добре. Після того, як ви зробите це, будь-які петлі 2 шару будуть порушені, швидкі мак-клапті припиняться, і це значно полегшує діагностику.

Ще пара глобальних команд, які корисні для відстеження портів, пов'язаних із штормом (mac-move) та затопленням (поріг) ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

Після того як ви закінчите, необов'язково зробіть clear mac address-tableприскорення зцілення з потенційно повного столу CAM.

• Ran show mac-таблиця адрес на різних комутаторах та самому ядрі (на ядрі, наприклад, підключений безпосередньо на робочому столі, на моєму робочому столі), і ми можемо бачити, як декілька різних MAC-апаратних адрес зареєстровані в інтерфейсі, хоча цей інтерфейс має до цього підключений лише один комп’ютер ...

Ця відповідь передбачає, що у вашого 3750 немає помилки, яка спричиняє проблему (але ви сказали, що проводка вказала на ПК, що заливаються). Те, що ви нам показуєте, очевидно помиляється, коли до Gi1 / 1/3 прикріплений лише один комп’ютер, якщо тільки на цьому ПК є щось на зразок VMWare.

Різні думки

На основі розмови в чаті, я, мабуть, не повинен згадувати очевидне, але я буду заради майбутніх відвідувачів ...

• Поставити будь-яких користувачів у Vlan1 - це звичайно погана ідея (я розумію, ви, можливо, успадкували безлад)
• Незалежно від того, що вам каже TAC, 192.168.0.0/20 занадто великий, щоб керувати в одному комутованому домені без ризиків атак layer2. Чим більша ваша маска підмережі, тим більше експозиції вам доведеться виконувати атаки layer2, як це, оскільки ARP - це несанкціонований протокол, і маршрутизатор повинен хоча б зчитувати дійсний ARP з цієї підмережі.
• Контроль над штормом на портах layer2 також є хорошою ідеєю; однак, якщо дозволити контроль над штормом у подібній ситуації, він спричинить добрий рух із поганим трафіком. Після оздоровлення мережі застосуйте деякі політики боротьби з штормом на ваших крайових портах та посиланнях.

Справжнє питання полягає в тому, чому господарі відправляють стільки ARP в першу чергу. Поки на це не відповідуть, комутатори продовжуватимуть важко справлятися з штормом арпи. Невідповідність маски? Низькі таймери арп-хостів? Один (або більше) хостів, що мають маршрут "інтерфейс"? Кудись бездротовий бездротовий міст? "безоплатний арп" зійшов з розуму? Зондування DHCP-сервера "під час використання"? Це не схоже на проблему з комутаторами або шаром 2; у вас господарі роблять погані справи.

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

(Чи станеться чимало таких хостів Linux-системами? У Linux була дуже гарна система управління кешем ARP. Факт, що він "повторно перевірить" запис за лічені хвилини, порушений у моїй книзі . У невеликих мережах це, як правило, менше, але a / 20 - це не мала мережа.)

Це може бути або не пов’язане з вашою проблемою, однак я подумав, що це може бути щось вигідне принаймні:

Наразі у нас є досить багато складених 3750x на деяких наших віддалених сайтах, здебільшого працює 15.0.2 (SE0 - 4, є деякі помилки FRU з SE0, з яких я повільно мігрую).

Під час звичайного оновлення IOS, починаючи з 15.0.2 до 15.2-1 (остання SE), ми помітили досить значне збільшення процесора, в середньому приблизно від 30% до 60% і вище в неробочий час. Я переглянув конфігурації та журнали зміни IOS та працював з TAC Cisco. За даними TAC, вони, здається, знаходяться в точці, коли вони вважають, що це якась помилка IOS 15.2-1.

Поки ми продовжували досліджувати збільшення процесора, ми почали бачити величезну кількість ARP-трафіку до того моменту, коли наші таблиці ARP повністю заповнювались і викликали нестабільність мережі. Тимчасовою миткою для цього було вручну повернути наші таймаути ARP подалі від дефолту (14400) до 300 для наших голосів і даних даних.

Після зменшення таймаутів ARP ми залишалися стабільними протягом тижня або близько того, після чого ми повернулися до IOS 15.0.2-SE4 і зняли нестандартні очікування ARP за замовчуванням. Наше використання процесора зменшилось до ~ 30%, а проблем з таблицею ARP немає.

Досить простий, але, можливо, непомічений; чи є у ваших клієнтів дійсний шлюз за замовчуванням, чи не ядро ​​ви робите багато проксі-серверів. Ви можете розглянути можливість заперечення функції arp ip proxy на вашому 3750?