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 что-то не помогают, хотя счётчик на аплинке тикает..

Есть ещё какие-то, не понятные флаги: "R.", "F.", "FP." С "точкой" в конце. 09:26:17.047681 IP 172.16.11.234.49478 > 178.248.237.177.443: Flags [R.], seq 4272666895, ack 1918564764, win 0, length 0 09:26:17.047866 IP 172.16.11.234.49467 > 178.248.237.177.443: Flags [R.], seq 2418366493, ack 1006666028, win 0, length 0 09:26:17.048139 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 2411951325, ack 2392870919, win 259, length 0 09:26:17.347547 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0 09:26:17.566650 IP 172.16.14.144.34852 > 213.180.204.145.443: Flags [R], seq 3070305443, win 0, length 0 09:26:17.807372 IP 172.16.4.151.52172 > 51.195.92.136.853: Flags [R], seq 2005766074, win 0, length 0 09:26:17.807919 IP 172.16.4.151.52172 > 51.195.92.136.853: Flags [R], seq 2005766074, win 0, length 0 09:26:17.821778 IP 172.16.4.151.56056 > 79.127.215.167.853: Flags [R], seq 3939105740, win 0, length 0 09:26:17.823751 IP 172.16.4.151.56056 > 79.127.215.167.853: Flags [R], seq 3939105740, win 0, length 0 09:26:17.907050 IP 172.16.4.151.60832 > 54.38.198.100.853: Flags [R], seq 2185298091, win 0, length 0 09:26:17.907634 IP 172.16.4.151.60832 > 54.38.198.100.853: Flags [R], seq 2185298091, win 0, length 0 09:26:17.908256 IP 172.16.4.151.52588 > 179.43.146.42.853: Flags [R], seq 1130723839, win 0, length 0 09:26:17.908748 IP 172.16.4.151.52588 > 179.43.146.42.853: Flags [R], seq 1130723839, win 0, length 0 09:26:17.944726 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0 09:26:19.150483 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0 09:26:19.182651 IP 172.16.12.223.44204 > 167.235.118.99.443: Flags [R], seq 3342213979, win 0, length 0 09:26:19.182670 IP 172.16.12.223.44204 > 167.235.118.99.443: Flags [R], seq 3342213979, win 0, length 0 09:26:19.267903 IP 172.16.12.223.48284 > 167.235.118.104.443: Flags [R], seq 2762067003, win 0, length 0 09:26:19.268051 IP 172.16.12.223.48284 > 167.235.118.104.443: Flags [R], seq 2762067003, win 0, length 0 09:26:20.007961 IP 172.16.3.41.64407 > 142.250.74.67.443: Flags [FP.], seq 4294967272:0, ack 1, win 388, options [nop,nop,TS val 3191474899 ecr 2887551799], length 24 09:26:21.545559 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0 Возможно. Фильтрация РКН у нас от аплинка. Но почему они с моей стороны мимо НАТа лезут?? Это же мои клиенты шлют ресеты.. Гм.. Мир перевернулся.. Всегда считал, что PRIVAT IP в Интернет - это нонсенс.. Ну или дурной тон, в лучшем случае. P.S. В принципе, можно было бы и забить на это всё, но у меня есть сильные подозрения, что от этого "мусора" со стороны провайдера страдает мой бордер. Уж очень совпадают всплески CPU LOAD по времени..

Не понял.. Какое правило "выше правила NAT"?? В POSTROUTING "выше" нет ничего для этой подсети. А на что обращать внимание? P.S. Что примечательно, наряду с "левым" мелким трафиком, от этого же IP идёт вполне легальный (уже "отначеный"), более "жирный". Т.е. получается как бы основная часть трафика идёт как положено, через NAT, а вторая, мелкая, NAT пытается обойти.. Бред какой-то... 😞

Добавил, но ничего не прояснилось.. Source MAC = MAC бордера (интерфейс с VLAN 62) Dest MAC = MAC интерфейса на коммутаторе (также на VLAN 62) Легальный трафик идёт в точности так же. Только с NAT SRC IP, а не со 172.16.ххх А это не могут быть какие-нибудь абонентские VPN-ы?

Разбираясь с in discards на порту аплинка (порт 28 DGS-3420), обнаружил во входящем трафике IP из privat network. Которые, похоже, и попадают в in discard (route в NULL на интерфейсе DGS). Провайдера уведомил, жду комментариев. Заодно решил посмотреть ситуацию на этом же порту со своей стороны. Обнаружил там небольшой исходящий траф из "абонентской" сети (172.16.0.0/12). Причём только исходящий. Типа такого: tcpdump -nn -i vlan62 src net 172.16.0.0/12 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan62, link-type EN10MB (Ethernet), capture size 65535 bytes 16:10:47.356822 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.357555 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.358528 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.359511 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.360488 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.361301 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.362974 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.363433 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0 16:10:47.642626 IP 172.16.1.115.55898 > 156.234.201.18.80: Flags [R.], seq 2140482065, ack 1575333553, win 0, length 0 16:10:47.674930 IP 172.16.10.74.44032 > 179.43.146.42.853: Flags [R], seq 238405226, win 0, length 0 16:10:47.674944 IP 172.16.10.74.44032 > 179.43.146.42.853: Flags [R], seq 238405226, win 0, length 0 Не пойму, что это за траф и как он пролезает через NAT? NAT такой - -A POSTROUTING -s 172.16.0.0/12 -o vlan62 -m set --match-set uplink src -j SNAT --to-source 111.222.200.137-111.222.200.190 --persistent В ipset uplink список тех самых 172.16... Манипуляции с цепочкой FORWARD (удаление из неё правила) -A FORWARD -s 172.16.0.0/12 -o vlan62 -j ACCEPT приводят только к полному пропаданию трафика.. Пока временно повесил на входящий порт DGS-а (от бордера) ACL с запретом 172.16.0.0/12. На аплинке исходящий от 172.16... пропал, но на "выходе" бордера всё по-прежнему..

А можно более развёрнуто? 1. кто виноват? 2. что делать? 3. надо ли вообще что-то делать?

BIND 9.10.2 довольно кучно гадит в лог следующим - Чтобы это значило?? root зону обновил ещё 5 января.

Broadcast на обоих коммутаторах, можно сказать, отсутствует. 2-5 frame/sec иногда проскакивает. Multicast - аналогично. Залетают иногда какие-то шальные пакеты. Вот и я не могу понять, что же это так напрягает CPU.. ACL на коммутаторе нет, Traffic control отключён. Зеркалируемые порты из traffic_segmentation исключены. Единственное, что активировано не по-дефолту - это multicast vlan_filtering_mode. Правда, я не наблюдал за содержимым трафика в ЧНН. Надо будет глянуть.. P.S. Есть ещё предположение, что источник проблемы не зеркалирование, а дропы на аплинке. Но и тут какая-то загадка - дропы видны только на графиках по snmp. Если глянуть ошибки на порту непосредственно в коммутаторе, то там их нет. От слова "совсем"..

Как оказалось, зеркалирование весьма тяжёлая задача для CPU коммутатора. Для примера - два одинкаовых коммутатора DGS-3420-24TC. CPU1 - только аплинк ~6Г в ЧНН. CPU2 - аплинк (1,4Г) плюс зеркалирование ~7,5 Г в ЧНН. Зеркалирую 5 пар 1Г портов (LACP) в один 10Г (СОРМ). MAC Learning на всех зеркалируемых портах выключен.

Гм.. По рублю. :-) Пишите в ЛС, поторгуемся. ;-)