Чому гальмує мережу
Чому повільно працює мережа?
Хааа, так що за тупе питання? Чому завгодно. 100500+ причин. Але тому що недавно зіткнувся з одним цікавим для себе малограмотного випадком, обов'язково його тут зазначу. Отже, в спрощеному до неподобства вигляді дана така вирізка з топологія LAN організації:
Але далі виникає така річ. З'являються дивні затримки при обміні пакетами між хостами, підключеними в різних ділянках LAN. Дивимося на картинку. Наприклад, звичайний ICMP ping від Хоста 1 до Хоста 2 (обидва знаходяться в VLAN 1) варіюється між 1 і 100+ msec, а деякі пакети взагалі пропадають. Здавалося б, як так може бути, якщо це LAN, а не інтернет і все лінки від хоста 1 до хоста 2 мають пропускну здатність не менше 1Гбіт сек. При таких умовах ping повинен стабільно літати туди-сюди за 1 мсек з оочень рідкісними девіацій від цієї цифри. Навіть якщо і завдяки флуду від ТК в мережі постійно висить паразитний фон в 10Мбміт / сек, це всього лише 1% від пропускної здатності каналу між Хостом 1 і Хостом 2. У чому ж проблема?
Як виявилося, проблема в деяких хостах, які як і раніше залишилися в першому VLANе і підключені до мережі АПЛІНК з пропускною спроможністю 10Мбіт / сек. Один такий хост і показаний на зображенні під ім'ям Linux Router і застромлять прямо в порт I2 кореневого комутатора Core 1 і знаходиться в VLAN 1. Хоч цей Linux Router і не лежить на шляху трафіку проходить від хоста 1 до хоста 2, він ще як впливає на швидкість проходження цього трафіку. Щоб зрозуміти, чому це відбувається, потрібно подивитися, наприклад, на лічильники інтерфейсу J1 Core 1.
Core1 # sh interfaces J1
Status and Counters - Port Counters for port J1
MAC Address. 0021f7-bc9c27
Link Status. Up
Totals (Since boot or last clear):
Bytes Rx. 812,984,141 Bytes Tx. 679,714,496
Unicast Rx. 2,571,865,283 Unicast Tx. 3,329,931,025
Bcast / Mcast Rx. 178,784,611 Bcast / Mcast Tx. 1,447,609,757
Errors (Since boot or last clear):
FCS Rx. 0 Drops Tx. 0
Alignment Rx. 0 Collisions Tx. 0
Runts Rx. 0 Late Colln Tx. 0
Giants Rx. 0 Excessive Colln. 0
Total Rx Errors. 0 Deferred Tx. 0
Others (Since boot or last clear):
Discard Rx. 10,086,697 Out Queue Len. 0
Unknown Protos. 0
Rates (5 minute weighted average):
Total Rx (Kbps). 453,128 Total Tx (Kbps). 449,464
Unicast Rx (Pkts / sec). 216,867 Unicast Tx (Pkts / sec). 109,209
B / Mcast Rx (Pkts / sec). 256 B / Mcast Tx (Pkts / sec). 107,624
Utilization Rx. 04.53% Utilization Tx. 04.49%
Що тут видно? Видно, що лічильник Discard Rx має непогане значення, яке постійно збільшується. Затурканість інтерфейсу за лічильниками Utilization Rx, Tx, як писалося вище, ну вже зовсім незначна, тобто з точки зору завантаження порти майже сплять. З усього цього, після довгих роздумів, народилося припущення, що відбувається все так (дивимося з позиції Core1):
2. Таких пакетів прилітає велика кількість і місця в черзі J1 стає ну дуууже мало, а в деякі моменти його немає взагалі.
В результаті, через одного тупого хоста, який погодив повільний лінк з комутатором рівня ядра, через який пролітає велика частина трафіку LAN повільно працює вся мережа. тому черги транзитних магістралей цього Core 1 геть забиті тим, чого чекає той, хто в даному випадку називається LinuxRouter. І велика пропускна здатність всіх АПЛІНК між комутаторами тут ну ніяк не допомагає.
У моєму випадку вилікувалося все вимиканням інтерфейсу I2 на Core 1. Це можна було зробити тому LinuxRouter вже давно ніким не використовувався і просто висів і працював як напівживий пам'ятник.
Хотів ще привести ті самі пінг із затримками до і після виключення I2 для більшої наочності, але, думаю, і так все зрозуміло.