megahertz0

Печаль-беда, придется в бюджет заложить еще 60к на 4908. Ну, в любом случае спасибо на информацию.

Привет! Есть необходимость поставить на узле циску 4900M в замен стека из 3750G. Нужно помимо десяток сделать с 4900M несколько гиговых линков. Вот что неясно. Действительно ли цисковские конвертеры CVR-X2-SFP работают только в X2 портах на half card и с бортовых X2 они тоже работают?

Спасибо, помогло.

Вот такой вопрос еще всплыл. На Junos можно ли сделать так чтобы префиксы, получаемые по BGP от апстримов, вообще не попалади в rib? Допустим я делаю reject каких-то префиксов, в active они пропадают, но все равно остаются в rib, правда в состоянии inactive. Вопрос в том как сделать так чтобы префиксы фильтровались наглухо и до rib не доходили ни в каком виде?

Всем привет! Пытаюсь настроить на Juniper MX балансировку между несколькими аплинками. От всех трех получаю дефолт + full view. Full view порезан, оставлен только дефолт. В настройках группу нейборов прописано: set protocols bgp group external-peers multipath multiple-as Вот что вижу у себя в show route 0.0.0.0 megahertz@mx80-ch19> show route 0.0.0.0 inet.0: 791521 destinations, 2291180 routes (97262 active, 0 holddown, 2099045 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 2w0d 13:48:14, MED 0, localpref 100 AS path: XXXX I, validation-state: unverified > to x.x.9.193 via xe-0/0/1.1054 to x.x.107.129 via ae2.922 to x.x.20.81 via xe-0/0/2.31 [BGP/170] 00:32:13, localpref 100 AS path: YYYY I, validation-state: unverified > to x.x.20.81 via xe-0/0/2.31 [BGP/170] 3w0d 17:23:25, localpref 100 AS path: ZZZZ I, validation-state: unverified > to x.x.107.129 via ae2.922 Но при этом трафик из моей AS наружу идет через одного аплинка. В чем может быть дело?

К счастью пока нет. Решаем тут задачу организации СОРМа нижестоящего провайдера. Надо на этапе реализации заглядывать в трафик, летящий в съемник с целью узнать все ли до него доходит. Реально трафика в десятке не в потолок же. Там от силы гигов 6-7. И из этого потока мне, к примеру, нужно выдернуть radius и сохранить на винт чтобы вайршарком посмотреть что там. Так что писать не так уж и много, обычный ssd справится. Железом можно фильтровать конечно. Но там не так уж и много возможностей. Тем более фильтры на том же 6500 работают для span на ingress. А мне трафик уже приходит, так что вариант фильтровать только на зонде, который захватывает трафик.

Привет! Возникла тут задача захвата трафика с 10G интерфейсов + немного capture filter чтобы на винт писать только то, что нужно. Реально ли такие объемы захватывать через tcpdump на линуксовом тазике с X520 и каким-нибудь не сильно древним ксеоном типа E56xx? Просто очень смущает возможность дропов и, соответственно, кривости дампа трафика. А готовой альтернативы tcpdump я не нашел. Все или в виде proof of concept или давно заброшено.

Такую бумажку я тоже видел. РТРС ей отписывался когда только запускал у себя отдачу потоков по земле. Первое время у них тоже все адски разваливалось. Мы приложили логи, в которых были CC Errors вне зависимости от рекламы. На что получили такую отписку. Самое прикольное, что ошибки со стороны РТРС четко совпадали с ошибками в T2-MI с 53 градуса, который к тому времени мы успели у себя принять чтобы обойти косяки местных умельцев. Вот такие дела.

Цена в 835к за коробку MSD это просто космос. Видимо у @sky star денег немерено. По теме вопроса мы у себя видели CC ошибки при втыкании местным РТПЦ вставок в федеральный сигнал. У них там, видимо, втыкалка не следит за целостностью таймкода в потоке и сует его от балды. Это и вызывает CC. Но это прямо в потоке от РТРС с их стримера. Мы у себя прогоняем сигнал через EMR 3.0 для DVB-C и через Астру для HLS. Развалов при этом в DVB и в IPTV не наблюдалось. Поэтому топикстартеру я бы порекомендовал собрать схему на триальной Астре в качестве рестримера и посмотреть как они будет работать. По идее должно помочь.

Так довольно давно есть многопортовые ONT с 8-24 портами FE: http://www.huaweigpon.cz/wp-content/uploads/MA5620-a-MA5626.pdf. Бонус - 8-24 FXS порта. Правда непонятно как это выглядит с точки зрения управления. Т.е. это прямо полноценная ONT с конфигурацией по OMCI/TR-069 или там PON и Ethernet разделены между собой. А меня вот интересует тема с использованием GPON ONT в формате SFP. Допустим, у нас в частном секторе популярны дома по 4-8 квартир. Можно решать вопрос традиционно, т.е. поставить делитель ONT по количеству абонентов. А можно поставить обыкновенный свитч и в него в качестве аплинка воткнуть GPON SFP. Такую схему кто-то использует?

Вот такими штуками пользуется уже много лет. В т.ч. и для длинных тяжелых железок. https://www.nix.ru/autocatalog/racks_accessories/NT-UNIRAILS-880-B-Napravlyayushhie-universalnye-1U-chyornye-regulirovka-750-1080-mm_161546.html

MySQL 5.7 насколько мне известно научился бить таблицы на партишены своими силами.

Чем покупать 15к диски, железный рейд и все такое проще купить пару SSD и жить спокойно. По деньгам даже дешевле выйдет при IOPS большем в десятки раз.

У нас вот такой конфиг работает года 3, мощи вполне хватает: Мониторит 1100+ узлов (свитчи в основном и около 40 серверов): В Zabbix нагрузка на сервер определяется по количеству NVPS (New Values per Second). Реально один сервер с конифгом как выше может прожевать 6-8к NVPS, а то и выше. Это весьма большой объем данных. В основном все упирается в БД. Поэтому общие рекомендации по поводу Zabbix сводятся к тому, что нужно иметь быструю БД, т.е. побольше памяти (в идеале чтобы БД помещалась целиком) и быстрые диски. Поэтому если вы планируете мониторить что-то более-менее серьезное, то сразу купите какой-нибудь БУ сервер типа Supermicro на Ксеоне E55xx/56xx и SSD под базу. Благо надежные SSD стоят сейчас недорого. Но это, опять же, если у вас БД будет весить хотя бы 20 гб и Zabbix будет обрабатывать 0,5-1к NVPS. Если будете мониторить пару десятков узлов с хранением статистики в пределах полугода-года, то пойдет любая тачка с любым распространенным Линуксом (Debian/Ubuntu/CentsOS) свежей версии, процом типа Core-i3 и 4 Гб памяти. Желательно еще подтюнить БД под возможности железа. Хорошее представление о масштабировании Zabbix дает вот эта статья, рекомендую с ней ознакомиться.

Вот какой итог получается. Обновил систему на Debian 8, ядро 3.16.56-1+deb8u1. SSD собрал в зеркало. Разметил на массиве раздел, отформатировал его в ext4 без какой-то особой магии и смонтировал. fstrim вроде выполнился: root@hs1:/home/megahertz# fstrim -v /var/lib/mysql /var/lib/mysql: 368,7 GiB (395904679936 bytes) trimmed Похоже и правда начиная с Debian 8 md научился пропускать fstrim до дисков.