[disappointed]

1 час назад, AlKov сказал:

Выключил LBD на порту аплинка - ничего не изменилось..

 

c0:a0:bb:dd:ee:11 это DGS? Порт на бордер, не выключилось значит.

[AlKov]

1 час назад, disappointed сказал:

c0:a0:bb:dd:ee:11 это DGS? Порт на бордер, не выключилось значит.

Да, это DGS. Только какой-то странный.. В ARP таблице коммутатора такого нет..

Оригинальный (я правил свои МАС-и в сообщении) MAC оканчивается на FE:00, а этот на FF:11

 

А с чего бы loopback  мог не выключится?

Цитата

Port   Loopdetect State    Loop Status
------ ------------------  -----------------------------------------------------
21     Enabled             Normal
22     Enabled             Normal
23     Enabled             Normal
24     Enabled             Normal
25     Enabled             Normal
26     Enabled             Normal
27     Enabled             Normal
28     Disabled            Normal

 

[witch]

 Не забывайте, что каждый  ip vlan будет иметь МАС из пула л3 свича, плюс cpu.  И вообще зачем на стыках поднимать LBD?

[AlKov]

12 минут назад, witch сказал:

Не забывайте, что каждый  ip vlan будет иметь МАС из пула л3 свича, плюс cpu. 

Ну так и есть: 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?

 

12 минут назад, witch сказал:

И вообще зачем на стыках поднимать LBD?

Да нет у меня на этом порту LBD. И не было до того как не озаботился помойкой на аплинке.

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

[disappointed]

14 часов назад, AlKov сказал:

Да нет у меня на этом порту LBD. И не было до того как не озаботился помойкой на аплинке.

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

 

Вы смотрите tcpdump со стороны бордера, я же пишу выше - отключить на порту который на бордер.

[AlKov]

В 23.03.2024 в 10:40, disappointed сказал:

Вы смотрите tcpdump со стороны бордера, я же пишу выше - отключить на порту который на бордер.

С петлёй разобрался. Действительно, это была "моя" петля. Петлял порт, на который зеркалировал аплинк.

Помог материал Функционал LoopBack Detection и раскрытие информации.

А вот про то, с чего всё началось, так и ничего не накопал..

Bogon network пров убрал с аплинка, но легче не стало..

Всё по-прежнему - discard in packet и соответствующий CPU Load, иногда доходящий до 60%.. 

 

[disappointed]

2 часа назад, AlKov сказал:

Всё по-прежнему - discard in packet и соответствующий CPU Load, иногда доходящий до 60%.. 

А ведь не факт, что есть прямая зависимость, идеально точного совпадения по времени я не вижу, там просто пик ЧНН.

Почему такой рваный CPU load, как будто там сервер 2010 года?

[AlKov]

4 часа назад, disappointed сказал:

А ведь не факт, что есть прямая зависимость, идеально точного совпадения по времени я не вижу, там просто пик ЧНН.

Да, всё так, но однозначная зависимость между трафиком, дискардами и CPU Load есть.

Кстати.. "Рваность" картинки CPU LOAD более соответствует "рваности" трафика.

 

 

 

4 часа назад, disappointed сказал:

Почему такой рваный CPU load, как будто там сервер 2010 года?

Так это не сервер, это CPU LOAD DGS-3420.

 

[vurd]

Можно глупый вопрос? А что мешает соединить напрямую аплинк с бордером без промежуточного свитча?

[AlKov]

14 часов назад, vurd сказал:

Можно глупый вопрос? А что мешает соединить напрямую аплинк с бордером без промежуточного свитча?

Религия(структура сети).  :) 

 

P.S. А по теме что-нибудь посоветуете?

Например, как узнать, что конкретно грузит CPU?

Да и собственно про discards in тоже не понятно. Что это и где?

На порту коммутатора (команда show error port 28) эти дискарды никак не отображаются.

Видно их только по snmp (OID ifInDiscards.28). Т.е. это ошибки на vlan интерфейсе порта.

[ixi]

18 часов назад, AlKov сказал:

но однозначная зависимость между трафиком, дискардами и CPU Load есть

она и должна быть. Если одновременно не появляются ошибки crc, с вашей или противоположной стороны, игнорируйте, их не так много.

 

Если хотите разобраться, на форуме длинка был полный перечень случаев для счётчика discards

[AlKov]

3 минуты назад, ixi сказал:

она и должна быть. Если одновременно не появляются ошибки crc, с вашей или противоположной стороны, игнорируйте, их не так много.

Дело в том, что на втором аплинке, на в точности таком же коммутаторе ничего подобного не наблюдается!

CPU LOAD стабильно держится в пределах 16-20% при трафике в 6 раз бОльшем! Дискардов нет совсем.

Схема подключения к серверам NAT и к провайдеру 100% аналогичная.

Единственное отличие "правильного" линка только в версии прошивки DGS-а. У него она "ниже".

Может быть эта версия просто "не видит" подобную ситуацию?

У обсуждаемого DGS-a FW.ver - Build 3.03.B017 (последняя), у "правильного" -  Build 3.01.R014.

 

11 минут назад, ixi сказал:

Если хотите разобраться, на форуме длинка был полный перечень случаев для счётчика discards

Тему видел, но применить к ситуации не смог.. 😞

[disappointed]

А если взглянуть tcpdump -i vlan62 -n -p arp -c10

то там что-то бегает или тишина?

Было у меня когда арп лукапы транзитом через 3120 проц в сотку ставили.

[AlKov]

3 часа назад, disappointed сказал:

А если взглянуть tcpdump -i vlan62 -n -p arp -c10

то там что-то бегает или тишина?

Вообще-то, vlan62 - это интерфейс, который смотрит в NAT сервер. 

Я ранее ошибся в схеме.. Вот нарисовал более подробную и правильную.

 

 

Но на всякий пожарный, посмотрел и там и там (на vlan63 интерфейсе).

На vlan63 arp-ов нет совсем, на vlan62 (смотрел непосредственно на сервере) есть чуть.

Но это легитимные запросы от DGS-а в свою подсеть (/29). Их совсем немного.

Цитата

18:46:19.045551 ARP, Request who-has 128.XXX.XXX.XX1 tell 128.XXX.XXX.XXX, length 46

                                                                                                        IP DGS-a

 

Что ещё заметил - количество discard резко возрастает при переходе трафика за 1Гб/с.

Такое ощущение, что работает один линк в LACP.

Но это не так..

 Port     TX/sec     RX/sec   Util
 -----  ---------- ---------- ----
 3      61301      41334      30 
 4      74676      33932      37

Иногда, правда, возникает какой-то подозрительный "перекос" -

Цитата

Port     TX/sec     RX/sec   Util    
 -----  ---------- ---------- ---- 
 3      55246      39523      26      
 4      82903      38749      43

В 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 Гб/с.

Вот ещё бы понять, что сие значит...

[disappointed]

Распределение на LAG нормальное.

Может убрать DGS вообще? Зачем этот свитч в роли бордера, что это даёт?

[witch]

6 минут назад, disappointed сказал:

Распределение на LAG нормальное.

Может убрать DGS вообще? Зачем этот свитч в роли бордера, что это даёт?

Видимо зеркало на 18 порт, и отсутствие 10г в нат

[disappointed]

Ну убрать маршрутизацию, 63 влан транзитом кинуть на брас и сделать из него бордер.

Кстати https://aliexpress.ru/item/32843645457.html

[AlKov]

11 часов назад, witch сказал:

Видимо зеркало на 18 порт, и отсутствие 10г в нат

Не в этом дело. 18 порт для зеркала - это вообще "времянка" для поиска проблемы.

10Г порта на NAT-сервере, действительно нет, но он и не нужен (пока), т.к. суммарный траф с каждого сервера NAT не превышает 1,5-1,7 Гб/с.

А NAT серверов, проброшенных в один аплинк, несколько (сейчас, правда, на этом аплинке остался один).

Отсюда и необходимость в DGS-е.

11 часов назад, disappointed сказал:

убрать маршрутизацию, 63 влан транзитом кинуть на брас и сделать из него бордер.

Это реально. Только вот решит ли проблему. И в случае добавления 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Г карту. Надо будет прикупить..

[disappointed]

В 27.03.2024 в 11:51, AlKov сказал:

Это реально. Только вот решит ли проблему.

 

Как минимум будет не опциональная для этого свитча маршрутизация я простейшей свитчинг.

 

В 27.03.2024 в 11:51, AlKov сказал:

И в случае добавления 2-3... NAT-сервера снова придётся уходить на DGS-маршрутизацию

 

Потому что не должен стоять свитч вместо бордера. Собирите простой тазик с парой x520. Сразу все эти древние 1G LAG-и уберутся.

Я на проце если не путаю Intel E3-1220 самой первой версии почти 10гигабит/1.5 мппс роутил на говнобордере, это с полными FV в количестве минимум 2 штуки было.