@lexey Опубликовано 5 ноября, 2007 · Жалоба Имеем HP 9304m в ядре сети, имеются подозрения в недостаточной пропускной способности девайса. Производитель заявляет Throughput: 83 million pps (64-byte packets)Routing/switching capacity: 128 Gbps c интервалом в 5 секунд собираю (perl-скрипт) сумму OID ifHCInUcastPkts (.1.3.6.1.2.1.31.1.1.1.7) для всех интерфейсов(32928668411893 - 32831796871237)/5 = 19.3743081 × 10^9 многовато :-) Вывод: я избрал неверный способ определения pps, либо неправильно понимаю этот параметр. Подскажите куда копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 6 ноября, 2007 · Жалоба размер пакетов играет большой рояль. Тяжелее всего пророутить мелкие пакеты(64 байта), именно на них и заявлено 83 миллиона пакетов в секунду. посчитайте, на каком числе пакетов в секунду у вас кончится пропускная способность каналов по схеме максимальной нагрузки. Например, каждую пару портов маршрутизировать только между собой. он у вас точно не коммутирует ничего? мож там есть пара портов на которых голая коммутация, из-за чего вам все сбивается... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 6 ноября, 2007 · Жалоба размер пакетов играет большой рояль. Тяжелее всего пророутить мелкие пакеты(64 байта), именно на них и заявлено 83 миллиона пакетов в секунду. то есть на пакетах по килобайту pps будет намного выше? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 6 ноября, 2007 · Жалоба размер пакетов играет большой рояль. Тяжелее всего пророутить мелкие пакеты(64 байта)они маленькие такие... стоко времени проходит, пока разглядишь... :) PS суммируя pps по всем портам, pps как минимум, удваивается, т.к. он учитывается на входящем и исходящем интерфейсах одновременно. PPS а точно 5 секунд? не 5 минут!? хотя всё равно много... цифра больше похожа на bps, может повнимательней в МИБы посмотреть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
@lexey Опубликовано 6 ноября, 2007 · Жалоба mikevlz Да, Вы правы, один модуль почти полностью коммутируемый (портов 12 из 16 имеющихся), и второй скорее всего тоже. Итого в маршрутизации участвуют около 15 портов. Если честно - я даже не подумал что следует разделять коммутируемые и маршрутизируемые пакеты. :lamer: суммируя pps по всем портам, pps как минимум, удваивается, т.к. он учитывается на входящем и исходящем интерфейсах одновременно. ifHCInUcastPkts - т.е. только входящие пакеты считаем, другой вопрос - те ли это пакеты которые нужны. цифра больше похожа на bps, может повнимательней в МИБы посмотреть?посмотрел, нашел столбец.iso.org.dod.internet.mgmt.mib-2.rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts (.1.3.6.1.2.1.16.1.1.1.5) Там цифры гораздо более приземленные (610605905-610586819)/5=3817.2, это на одном из интерфейсов. Если же суммировать показания на всех интерфейсах наблюдаются аномалии на пустых портах - показания меняются не в сторону увеличений, а куда попало. Вот результаты нескольких последовательных запусков моего скрипта: 4684977646956651928197 61345137789 71307513405 53949811758 55287944457 59188075307 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 6 ноября, 2007 (изменено) · Жалоба я не силен именно в этой железке, но я бы попробовал сравнить эти показания с чем-нибудь типа sh int stats на каталистах.... чтобы правильно выделить именно L3 на портах, ИМХО, надо очень хорошо знать железку и не факт что это вообще возможно. у самой маршрутизации скорее всего есть свои счетчики не привязанные к портам (или интерфейсам?) и еще... 83Mpps в реальной жизни это однозначно больше 200Gbps, а то и весь 1Tbps. Стоит ли заморачиваться? Изменено 6 ноября, 2007 пользователем desperado Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
@lexey Опубликовано 7 ноября, 2007 · Жалоба desperado В принципе уже стало понятно, что затык явно не в этой железке происходит, к тому же утилизация ЦП не превышает 5 %. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 7 ноября, 2007 · Жалоба desperadoВ принципе уже стало понятно, что затык явно не в этой железке происходит, к тому же утилизация ЦП не превышает 5 %. не знаю прочих обстоятелств, но, по крайней мере, на одну только загрузку процессора я бы полагаться не стал. 83Mpps не пророутит ни один процессор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
@lexey Опубликовано 7 ноября, 2007 · Жалоба desperado Не сочтите за наглость, не могли бы вы привести свою методику проверки такого рода железок (на какие параметры и в каком порядке стоит обратить внимание), теорией то сыт не будешь... а опыта маловато. ;-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 7 ноября, 2007 · Жалоба по HP не подскажу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...