AlKov

Не в этом дело. 18 порт для зеркала - это вообще "времянка" для поиска проблемы. 10Г порта на NAT-сервере, действительно нет, но он и не нужен (пока), т.к. суммарный траф с каждого сервера NAT не превышает 1,5-1,7 Гб/с. А NAT серверов, проброшенных в один аплинк, несколько (сейчас, правда, на этом аплинке остался один). Отсюда и необходимость в DGS-е. Это реально. Только вот решит ли проблему. И в случае добавления 2-3... NAT-сервера снова придётся уходить на DGS-маршрутизацию.. Вообщем, надо пытаться найти источник проблемы. Мне бы вот с этой шифровкой разобраться OS_UTIL 56 % 57 % 60 % FWD-ETH 15 % 14 % 13 % bcmRX 11 % 11 % 10 % Вот эта табличка, когда дискардов почти нет и CPU Load 18% Process Name 5Sec 1Min 5Min ----------------- ------ ------ ------ OS_UTIL 84 % 79 % 79 % bcmL2X.0 4 % 3 % 3 % FWD-ETH 3 % 3 % 3 % bcmRX 3 % 3 % 3 % HISR1 2 % 2 % 2 % bcmCNTR.0 2 % 2 % 2 % DDM_TIC 1 % 2 % 2 % GBIC_Pooling 0 % 1 % 2 % Или "расшифровка" ничего не даст? P.S. Благодарю за ссылку на 10Г карту. Надо будет прикупить..

Вообще-то, vlan62 - это интерфейс, который смотрит в NAT сервер. Я ранее ошибся в схеме.. Вот нарисовал более подробную и правильную. Но на всякий пожарный, посмотрел и там и там (на vlan63 интерфейсе). На vlan63 arp-ов нет совсем, на vlan62 (смотрел непосредственно на сервере) есть чуть. Но это легитимные запросы от DGS-а в свою подсеть (/29). Их совсем немного. Что ещё заметил - количество discard резко возрастает при переходе трафика за 1Гб/с. Такое ощущение, что работает один линк в LACP. Но это не так.. Port TX/sec RX/sec Util ----- ---------- ---------- ---- 3 61301 41334 30 4 74676 33932 37 Иногда, правда, возникает какой-то подозрительный "перекос" - В 1,7 раза.. Посмотрел аналогичные линки на "правильном" коммутаторе - там разница не более 10%. Может отсюда эти ноги растут? И я не там ищу.. Глянул дебаг cpu util debug show cpu utilization Five seconds - 47 % One minute - 44 % Five minutes - 40 % Process Name 5Sec 1Min 5Min ----------------- ------ ------ ------ OS_UTIL 56 % 57 % 60 % FWD-ETH 15 % 14 % 13 % bcmRX 11 % 11 % 10 % HISR1 5 % 5 % 4 % DDM_TIC 4 % 2 % 2 % bcmL2X.0 4 % 3 % 3 % bcmCNTR.0 2 % 2 % 2 % GBIC_Pooling 1 % 2 % 2 % bcmTX 1 % 1 % 1 % Сравнил с "правильным" коммутатором debug show cpu utilization Five seconds - 19 % One minute - 18 % Five minutes - 18 % Process Name 5Sec 1Min 5Min ----------------- ------ ------ ------ OS_UTIL 83 % 82 % 82 % bcmL2X.0 4 % 3 % 3 % DDM_TIC 2 % 2 % 2 % bcmRX 2 % 2 % 2 % GBIC_Pooling 2 % 1 % 1 % FWD-ETH 2 % 2 % 1 % bcmCNTR.0 2 % 2 % 2 % HISR1 1 % 1 % 1 % LacpRx 1 % 1 % 1 % Разница заметная. Особенно, учитывая тО, что второй обслуживает 4 LAG пары, при суммарном трафике > 6 Гб/с. Вот ещё бы понять, что сие значит...

Дело в том, что на втором аплинке, на в точности таком же коммутаторе ничего подобного не наблюдается! CPU LOAD стабильно держится в пределах 16-20% при трафике в 6 раз бОльшем! Дискардов нет совсем. Схема подключения к серверам NAT и к провайдеру 100% аналогичная. Единственное отличие "правильного" линка только в версии прошивки DGS-а. У него она "ниже". Может быть эта версия просто "не видит" подобную ситуацию? У обсуждаемого DGS-a FW.ver - Build 3.03.B017 (последняя), у "правильного" - Build 3.01.R014. Тему видел, но применить к ситуации не смог.. 😞

Религия(структура сети). :) P.S. А по теме что-нибудь посоветуете? Например, как узнать, что конкретно грузит CPU? Да и собственно про discards in тоже не понятно. Что это и где? На порту коммутатора (команда show error port 28) эти дискарды никак не отображаются. Видно их только по snmp (OID ifInDiscards.28). Т.е. это ошибки на vlan интерфейсе порта.

Да, всё так, но однозначная зависимость между трафиком, дискардами и CPU Load есть. Кстати.. "Рваность" картинки CPU LOAD более соответствует "рваности" трафика. Так это не сервер, это CPU LOAD DGS-3420.

С петлёй разобрался. Действительно, это была "моя" петля. Петлял порт, на который зеркалировал аплинк. Помог материал Функционал LoopBack Detection и раскрытие информации. А вот про то, с чего всё началось, так и ничего не накопал.. Bogon network пров убрал с аплинка, но легче не стало.. Всё по-прежнему - discard in packet и соответствующий CPU Load, иногда доходящий до 60%..

Ну так и есть: VID 3 - C0-A0-XX-XX-FE-00 VID 63 - C0-A0-XX-XX-FE-01 VID 62 - C0-A0-XX-XX-FE-02 И эти МАС я вижу в арп. А тот, который шлёт луп-детект - C0-A0-XX-XX-FF-11 В арп его нет.. Это что за интерфейс? Или это и есть МАС CPU? Да нет у меня на этом порту LBD. И не было до того как не озаботился помойкой на аплинке. Для интересу подёргал туда-сюда, но никаких отличий не обнаружил и оставил в DISABLE.

Да, это DGS. Только какой-то странный.. В ARP таблице коммутатора такого нет.. Оригинальный (я правил свои МАС-и в сообщении) MAC оканчивается на FE:00, а этот на FF:11 А с чего бы loopback мог не выключится?

Выключил LBD на порту аплинка - ничего не изменилось.. P.S. Глянул на "нормальном" аплинке на предмет Loopback - "левый траф" прилетает (причём, с тех же самых IP!!), но петель нет.. Походу, это всё-таки какие-то "неправильные пчёлыLoopback". P.P.S. Интересный каламбурчик вышел про неправильных пчёл. "Кривой" аплинк как раз "пчелиный" (Beeline) 🙂

Да хз.. Общаюсь по е-мейл через "говорящие головы" ТП, которые только пересылают инфу к технарям и обратно. Но надо отдать должное - помойку из bogon network всё же сегодня они мне ликвидировали. :-) Квест с loopback пока не пройден..

Про это я в курсе. Но.. С чего бы им появляться, да ещё со статусом "invalid"? Это разве тоже нормально? Вот смотрите, что за ситуация происходит: 194.XXX.XXX.XXX/30 - это мой "линковочный" IP. На него с какого-то перепугу пров шлёт мне "чужие" IP, про которые бордер ничего не знает и честно оправляет их взад (в дефаулт) прову. Шлюз со стороны прова имеет IP из 194.XXX.XXX.XXX/30. Предполагаю, что отсюда и вылезают те самые Loopback. Или я ошибаюсь?

Вот ещё нарыл на аплинке Вот эти " Loopback (0x9000), Loopback, skipCount 0" - не есть ли причина discard packet и загруза CPU? И вообще, что это за петли? routing loops, или что-то другое? И чья сторона является причиной?

RFC1918

Это я уже сделал. Остался пров, который продолжает лить ко мне "левак". И задавать при этом весьма интересные вопросы - Мол чё тебе, парниша, весёлые картинки не нравятся?! :)

Помогло! За 10 мин. всего 8 icmp пакетов. Всё остальное исчезло. Благодарю! P.S. Вот как бы ещё дискарды убрать с аплинка.. Может убрать с DGS-а NULL route PRIVAT net? Завернуть их на бордер. Нехай он их дропает. Или вообще, обратно прову вернуть по дефаулт роут? ACL что-то не помогают, хотя счётчик на аплинке тикает..