У невеликому коледжі, де я працюю, виникають дуже дивні проблеми з мережею. Я шукаю тут будь-яку пораду чи ідеї. Нам було добре влітку, але біда почалася через кілька днів після того, як студенти повернулися до кампусу, що діють на осінній термін.
Симптоми
Основним симптомом є те, що доступ до Інтернету буде працювати, але це дуже повільно ... часто до моменту очікування. Наприклад, типовий результат Speedtest.net поверне завантаження .4Mbps, але дозволить швидкість завантаження від 3 до 8 Мбіт / с. Менші симптоми можуть включати сильно обмежену продуктивність передачі даних на наш файловий сервер і з нього, або навіть у деяких випадках неможливість увійти до комп'ютера (не може дійти до контролера домену). Випуск перетинає кілька власних властей і впливає на пристрої майже на кожній владі.
Проблема стосується не всіх машин у мережі. Непорушена машина зазвичай бачить принаймні 11 Мбіт / с, завантажену з speedtest.net, і, можливо, набагато більше, залежно від більшої структури трафіку в кампусі на той час.
Існує одна варіація щодо більшого питання. У нас є один влан, де користувачі взагалі не змогли увійти в майже всі машини. ІТ-персонал увійде в систему за допомогою облікового запису місцевого адміністратора (або в деяких випадках кешованих облікових даних), а звідти випуск / оновлення або пінг-шлюз дозволить машині працювати ... деякий час. Ускладнення цього питання полягає в тому, що ця vlan охоплює наші комп'ютерні лабораторії, які використовують програмне забезпечення під назвою Deep Freeze для повного скидання жорстких дисків після перезавантаження. Це може бути те саме, що проявляється по-різному через несвіжі дані на машинах, які протягом тижнів не змінювали постійно інформацію про низький рівень. Однак нам вдалося вирішити це, створивши новий влан і перемістивши лабораторії до нового влан оптом.
Підпитки
Врешті-решт ми помітили, що у всіх працюючих машин були недавні оренда dhcp. Ми можемо передбачити, коли машина стане "повільною", спостерігаючи, коли оновлює dhcp для поновлення. Ми грали з тим, щоб встановити термін оренди дуже короткий для тестового влану, але все, що було зроблено, це усунути нашу здатність передбачати, коли машина стане повільною. Машини зі статичними IP-адресами майже завжди працюють нормально. Вручну вивільнення / поновлення адреси ніколи не призведе до того, що машина стане повільною. Насправді в деяких випадках цей процес був зафіксованиймашина в такому стані. Однак більшість часу це не допомагає. Ми також помітили, що мобільні машини на зразок ноутбуків, швидше за все, стануть повільними, коли вони перейдуть на нові влани. Бездротова мережа в кампусі поділяється на "зони", де кожна зона відображає невеликий набір будівель. Переїзд до нової будівлі може розмістити вас у зоні, тим самим змусивши вас отримати нову адресу. Максимальна ймовірність того, що машина, що відновиться до режиму сну, також буде повільною.
Пом'якшення наслідків
Іноді, але не завжди, очищення кеш-пам'яті arp на здійсненій машині дозволить знову працювати нормально. Як уже було сказано, вивільнення / оновлення IP-адреси локальної машини може виправити цю машину, але це не гарантується. Пінгінг шлюзу за замовчуванням також іноді може допомогти для повільної машини.
Що, здається, найбільше допомагає пом’якшити проблему - це очищення кеш-пам'яті arp на нашому основному комутаторі шару-3. Цей комутатор використовується для нашої системи dhcp як шлюз за замовчуванням для всіх vlans, і він обробляє маршрутизацію між vlan. Модель - 3Com 4900SX. Щоб спробувати пом'якшити проблему, у нас встановлений тайм-аут кешу на комутаторі аж до мінімально можливого часу, але це не допомогло. Я також склав сценарій, який працює кожні кілька хвилин, щоб автоматично підключитися до комутатора та скинути кеш. На жаль, це не завжди працює, і навіть може призвести до того, що деякі машини за короткий час закінчуються у повільному стані (хоча, здається, вони виправляються через кілька хвилин). Наразі у нас є запланована робота, яка працює кожні 10 хвилин, щоб змусити основний перемикач очистити це кеш ARP, але це далеко не ідеально або бажано.
Відтворення
Зараз у нас є тестова машина, яку ми можемо примусити уповільнений стан за бажанням. Він підключений до комутатора з портами, встановленими для кожного з наших вланів. Ми робимо машину повільно, підключаючись до різних вланів, а після нового або двох з'єднань буде повільним.
Також у цьому розділі варто зазначити, що це сталося раніше на початку попередніх термінів, але в минулому проблема пішла самостійно через кілька днів. Це вирішилось перед тим, як ми мали можливість провести велику діагностичну роботу ... звідси, чому ми дозволили йому так довго затягуватися в термін цього разу; очікував, що це буде недовговічною ситуацією.
Інші фактори
Варто зазначити, що у нас було близько півдюжини вимикачів, які просто вийшли з ладу за останній рік. В основному це 3Coms епохи 2003/2004 років (в основному 4200), які були введені приблизно в один і той же час. Вони все ще повинні покриватися гарантією, купити HP зробило отримання сервісу дещо складним. Переважно в джерелах виходу з ладу джерел живлення, але в декількох випадках ми використовували джерело живлення від перемикача з невдалою материнською платою, щоб повернути вимикач з несправним джерелом живлення. Зараз у нас є пристрої ДБЖ на всіх, крім трьох з чотирьох комутаторів, але це було не так, коли я почав два з половиною роки тому. Суворі бюджетні обмеження (ми знаходилися в списку фінансово складних установ Еда пару років тому) змусили мене шукати заміни Netgear і TrendNet,
Варто також зазначити, що велика зміна в нашій мережі цього літа була міграцією з єдиного бездротового SSID між кампусом на згаданий раніше підхід. Я не думаю, що це джерело питання, як я вже казав: ми це бачили і раніше. Однак можливо, це загострює проблему, і це може бути значною мірою причиною того, що її так важко виділити.
Діагностика
Спочатку нам здавалося зрозумілим, враховуючи терміни та постійний характер проблеми, що джерелом випуску є заражений (або зловмисний) студентський апарат, який здійснював отруєння кешем ARP. Однак неодноразові спроби ізолювати джерело не вдалися. Ці спроби включають численні сліди пакетів проводів, і навіть короткі періоди роботи в режимі офлайн. Ми навіть не змогли знайти куріння гарматичного ARP. Моя поточна найкраща здогадка - це перевантажений або несправний основний комутатор, але я не впевнений, як перевірити це, і вартість його заміни сліпо зростає.
Знову будь-які ідеї цінували.
Оновлення:
Основний перемикач замінено. Через 4 дні все працює добре ... але я зачекаю два тижні, перш ніж виклик буде вирішено.
mtrможе бути тут корисним.