agr

Это происходит из-за разных механизмов ограничения скорости. shaper управляет исходящей полосой путем задержки отправления исходящих пакетов, policer управляет входящей полосой путем дропа входящего трафика превышающего установленные объемы. Указанный juniper'ом нижний предел burst-time в 5 миллисекунд - это чрезвычайно малое значение. Значения burst выбирайте в интервале 0.2-1 секунд. Причем чем выше CIR, тем меньше должно быть время burst. Также видимый эффект действия полисера зависит от количества работающих через "полисируемый" интерфейс TCP сессий - чем больше сессий, тем менее важен размер burst. Т.е. например, грубо говоря, на гигабитном полисере при ста tcp сессиях любой burst будет приемлем, но при одной tcp сессии никакой burts не обеспечит плавной загрузки полосы - в этом случае график загрузки будет всегдя иметь зигзагообразный вид. Это косяк не juniper, а технологии в принципе, policer на cisco будет выглядеть так же. Можете рассказать клиенту про Token bucket алгоритм(именно по нему работает policer) и про протокол TCP, скорость передачи по которому варьируется в зависимости от потерь на канале. Также можете предложить клиенту замерить скорость утилитой iperf в UDP поток заданной ширины или в несколько(не меньще 5) параллельных TCP потоков. ЗЫ: советую делать CIR процентов на 10 больше номинальной скорости, чтобы сгладить оверхед служебных заголовков, так у клиентов будет меньше вопросов возникать...

Хе, чукчи-писатели набижали.

Еще раз: "ресурсы" "компьютера" будут использоваться пропорционально нагрузке на сервер. Безотносительно используемого сервиса(DNS-, HTTP-, MAIL- etc сервер), более производительной будет установка ПО сервиса на отдельный выделенный сервер, чем на точно такой же сервер, но внутрь виртуальной машины. Происходит это потому, что во втором случае сервер будет тратить свои "ресурсы" не только на выполнение ПО сервиса, но и на виртуализацию ОС, в которой запущено это ПО. А следовательно ПО получит меньше "ресурсов", чем в первом случае. Неужели для вас неочевидна эта простая причинно-следственная связь?

Прочитайте уже в Интернете что такое SNMP и MIB, разжевывать базовую теорию вам никто не будет. Или поручите админу, если он смог поставить nagios, то и как сделать snmpwalk должен осилить.

Исходите из планируемой нагрузки на DNS-сервер - сколько будет запросов к нему вообще и сколько из них рекурсивных. В Ънтерпрайзе нагрузка скорее всего будет чуть менее чем никакая, так что спокойно ставьте в виртуалку на винде.

Настроить SNMP агент и сделать snmpwalk на корневой OID.

Оба плагина используют стандартную RFC'шную(т.е. не vendor'скую) SONET-MIB, если оборудование ее поддерживает, то плагины заработают. Найти ее в Интернетах - http://www.oidview.com/mibs/0/SONET-MIB.html .

Попробуйте из хост машины вообще удалить всю связнную с vlan конфигурацию. У меня на более древнем ядре бриджинг тегов работает, правда у меня двойное тегирование применяется, выглядит примерно так: 2900 - это s-vlan, он отдается с порта коммутатора как обычный тегированный влан(switchport trunk allowed vlan add 2900). C-vlan'ы упаковываются в s-vlan еще на вышестоящем оборудовании. На хост машине есть бридж куда приписан тегированный интерфейс с s-vlan'ом и интерфейс гостевой машины [root@host-node ~]# brctl show bridge name bridge id STP enabled interfaces br1 8000.003048d671d9 no vif1.1 eth1.2900 На хост-машине никакой конфигурации связанной с клиентскими c-vlan'ами вланами нет, она о них ничего не знает. На гостевой машине c-vlan'ы добавляются vconfig'ом и про s-vlan гостевая машина ничего не знает. При такой настройке пакеты ушедшие с порта коммутатора с двойным тегом успешно прилетают в гостевую ОС с единичным тегом и наоборот. Еще как вариант, если очень не хочется использовать стороннее железное решение, то можно под каждый влан делать бридж, в который включать тегированный интерфейс в хост-машине и _отдельный_ физический интерфейс в гостевой машине. Минус в том, что при добавлении вланов придется перезапускать виртуалку(если конечно в kvm нельзя на горячую интерфейсы добавлять)

А физические интерфейсы хост-машины к бриджу то приписаны?

В догонку хантерам на редактирование После слова "абонентских" напрашивается существительное во множественном числе. К сожалению, не помню как в русском языке называется эта отсутствующая часть речи:( звучит слишком категорично, IMHO. Вы ищете многопрофильника - есть они, но не то чтобы массово(про Билайн-Мегафон это вы в точку), однако 100%-ю собственную доступность многопрофильник будет поддерживать либо в компании, в которой он вырос, либо где он является единственным управляющим сетью/серверами/etc. Первый случай не ваш, а во втором размеры оклада, очевидно, должны лежать в других диапазонах. Если есть несколько таких дублирующих друг друга спецов, то я бы написал в обязанностях что-то вроде "регулярные offline-дежурства с необходимостью круглосуточной...(далее по тексту)"

nmap вестимо запускался без service version scan.

В играх, где есть локально установленнное клиентское приложение, "ресурсный" контент по сети не передается. По сети идут только те данные, на основе которых локальная машина используя собственное хранилище "контента" сможет воспроизвести процесс игры. Именно поэтому в играх "пинг" важнее полосы. Самый каноничный пример - Контра(Прохожему привет), где при помощи модов на локальной тачке можно поменять абсолютно все текстуры, но по сети все равно будут ходить только координаты, угол обзора, здоровье, и амуниция игроков; время выстрела и направление пуль. Рядовой трафик online-игр - ничтожен. Здесь периодически в X.Y.Z. возникают темы о всплеках трафика при обновлении "Танчиков", так вот это и есть "ресурсный" контент.

У меня по средней кнопке открываются, браузер - фаерфокс 22 по линукс.

У APC есть девайсы такого класса http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=AP7721 . Как и у всего их оборудования есть интерфейс SNMP, очень удобно приклеивать к различным системам мониторинга, можно снимать как наличие питания на вводах, так и потребляемую мощность. Ещё здесь на форуме N лет назад какая-то отечественная контора предлагала аналоги, но ЕМНИП её продукцию, как водится, заочно заплевали. Ещё если есть свой толковый энергетик, то он сам может спаять нужную конструкцию из имеющихся в широкой продаже компонентов(различных реле и т.п.). Ещё занимающиеся продажей и установкой различной электрики конторы могут предложить варианты АВР в щитовом исполнении, в 19'' стойку не вмонтируешь, но в шкаф вполне можно щиток прикрутить.

А что за оборудование в стойке? Нет ли вторых блоков питания? У многих cisco, например, есть отдельный разъем RPS, можно его использовать для мягкого переключения на другие розетки. Ещё можно попробовать врезать АВР между ups и розетками, это по крайней мере может привести только к перезагрузке, но не к выгоранию. Включение второго ввода даже с переведением ups в bypass считаю крайне опасным вариантом. Если есть свободный ups, то надо попробовать на лабе; если его нет, то рисковать стойкой железа не стоит...

А у блоков розеток два входа? Если да, то в блоки должно быть встроено устройство АВР(автоматический ввод резерва). Если АВР нет, то в общем случае нельзя просто так взять и подать дополнительно 220В на блок розеток.

Неидентичные величины или величины с сильно различающимися размерностями стоит разносить по разным графикам. К слову, несвязанные напрямую величины не стоит делать STACK'ами на одном графике, сделайте line'ами, а то так сложно оценить абсолютное значение каждого параметра. STACK'и в основном используют на аггрегирующих графиках, например когда надо на один график вывести суммарный трафик с нескольких интерфейсов, или например свободное/занятое пространство на нескольких дисках.

Нет, SPA8000 - это не станция. Каждая линия отдельно регистрируется на SIP-шлюзе(не обязательно на одном и том же), на этом SIP-шлюзе и нужно настраивать маршрутизацию вызовов.

Так же как и с трафиком интерфейсов надо использовать "Data Queries".

По шаблону графика не совсем понятно, что хотите получить. Но вообще STACK'и наслаиваются поверх AREA, видимо из-за этого и ошибка RRDTool.

stack :) прилагаю скриншот для аггрегированого трафика с нескольких серверов, для сетевых аплинков то же самое будет. Как писал предыдущий оратор надо нужные datasource выбирать в каждом item'е. Делайте пары gprint и stack для каждого datasource, чтобы и на графике и в легенде отображалось.

То есть они сказали, что при построении фильтра ваших анонсов они при получении префикса из вашего объекта анонсирования(AS или AS-SET) не смотрят есть ли другой такой же route-объект с другим origin? Так такое, конечно, никто у нас в Европе не делает, не только Ретн. Вы, кстати, можете сами посмотреть какие ваши префиксы попадут в фильтр анонсов, воспользовавшись известной утилитой bgpq(кстати написанной одним из инженеров Ретн).

под "ничего" они должно быть имели ввиду не совсем ничего, а только префиксы объекта, который вы укажете. Fullview или чужие префиксы они вам явно не позволят в себя влить.

Нет, в route-объекте нельзя задать AS-SET в origin. route-объект у вас будет один с одной любой из ваших AS в origin. Далее создаете объект AS-SET и в него прописываете обе AS в members, далее сообщаете аплинкам.

очевидно вы имели ввиду "использовать во второй точке ASN#1 рассматриваем только как экстренный" ? Если все и так работает, то не трогайте. Если будут проблемы с прохождением префиксов, то создайте AS-SET и включите в него обе AS. Далее скажите обоим аплинкам, чтобы отныне строили фильтры на вашей сессии по AS-SET'у, а не по AS.