philippe46

>IP demux interface >Dual Stack >Не видеть здесь противоречие Второе - чего вы так привязались к IP-demux интерфейсам? Зачем нам один? Мы ведь хотим понять как полисер повесить на dual stack?

Как с Вами скучно. Предвзятость - самое ужасное что может быть в сфере Интернет, еще ужасней - accel-ppp. Juniper даст Вам это сделать. Кажись понял, в чем (в вашем случае) проблема, но наверное воздержусь от дальнейшего постинга во избежания чего-то опасного. ???

Подумать над этим вопросом еще раз: первое подумать чем отличается очередь от фильтра (классификатора). Как только поймете в вашем конкретном случае (оборудовании), пишите. Не подумайте, что я грублю, я просто не могу ответить вам более развернуто.

Прошу не горячиться. Много европейских провайдеров также с мертвой точки не двигается. Проблема здесь именно в банальной лени, и нежелании менять то что работает. Насчет железок, то единственный серьезный вопрос это ужасные CPE, которые если Dual-Stack поддерживают, то и то хорошо. Все остальные технологии, когда в сети только IPv6 бегает, а IPv4 инкапсулируется сейчас сильно слабо развиваются, только благодаря какому нибудь OpenWRT да стараниям Juniper: * 464xlat (так-себе, но еще более-менее) * MAP-T/MAP-E - совсем печально * ds-Lite (более-менее) * lw4over6 - совсем печально. Никто в здравом уме ту хрень использовать не будет на базе poll-based приложения и v-MX. Это Интернет. Нельзя просто взять и изменить все сети, иначе это не был бы Интернет. Каждый делает по мере возможностей. О туннелях 6over4 через брокеров - выбросите их к чертовой матери, и внедрите связности сами: это не сложно, и не нужно зависеть от доброй воли брокера. О нужде - да нужно. И должно быть очевидно вполне почему. Как минимум, программистам городить огород хаков для связи через NAT уже достало. Это самый минимум. Ровно как и снять нагрузку с CGNAT тоже хочется: мобильщики заинтересованы в этом в первую очередь, ну не наши правда (Киевстар довольно крупные дегенераты). В одну очередь классифицировать трафик не вариант?

???

В OpenWRT прошить не вариант? https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb962uigs-5hact2hnt_hap_ac Собрать самому образ с веб-сервером нужным в составе, и каким-нибудь там python микроскопическим, либо на С написать. Там будет в качестве libc - musl. Собрать под MIPS32 24Kc без FPU. Процедура заливки стандартна до боли: * сделать бэкап конфига, лицензии, и тп. * в прошивку собрать rbcfg (чтобы конфиг загрузчика менять). Выбрать таргет ar71xx и профиль Mikrotik с NOR-флешкой. * перевести на загрузку через netboot с DHCP * скачать для загрузки минимальный образ openwrt для netboot (initramfs): https://downloads.openwrt.org/snapshots/targets/ar71xx/mikrotik/openwrt-ar71xx-mikrotik-rb-nor-flash-16M-ac-initramfs-kernel.bin * поднять TFTP и отдать через next-server и filename файл на загрузку * запустить, дождаться загрузки, подключиться * залить свой образ (sysupgrade который) через wget и локальный веб-сервер на /tmp * выполнить sysupgrade для заливки образа на NOR флешку

Отличный вопрос в 2016 году. Тут уже дело за v6-only сетями, а не дуалстеком.

Должен всосать. Там на RS сейчас 16K маршрутов где-то.

До замены CCR как временное решение - увеличивайте размеры очередей (у вас сейчас это очереди packet_50M и так далее ) которого явно мало даже под 40 мбит среднестатистического абонентского трафика. Пробуйте идти в этом направление, может получиться хоть немного сбавить нагрузку. Ограничение происходит только в листах, помните об этом. Попробуйте поменять размеры ведер.

Не использовать Mikrotik CCR на RouterOS в провайдерском секторе. Никогда более. Это закрытый код. Дать работу на закрытие багов, приводящих к такой заднице вы никому не можете, поскольку это закрытый продукт пусть и на базе открытого ядра. Если выбираете программную маршрутизацию, то выбирайте открытые решения, которые специалисты нужного уровня смогут настроить и доделать под Вас. Для вашей нагрузки вам должно хватить Core i5, берите сразу на Skylake с DDR4 если делаете новую сборку. Если есть какие-либо вопросы - велкам в ЛС. Покупайте сетевые на базе Intel чипа, ставьте Debian Linux, работайте с намного меньшей загрузкой и ждите новостей по пакетной акселерации.

Я сказал бы обратное - достаточно дешевые. Нет, серьезно. Это устройства на базе Tilera - многоядерного CPU с 64-битной архитектурой. Обработка трафика - задача высоко параллельная. К сожалению, я не могу рассматривать RouterOS как нечто серьезное, которое смогло бы раскрыть их полный потенциал. А потенциал там большой - от создания крутого софтового роутера до IPS/IDS. Железо приятное в CCR, но софт... Честно сказать - очень интересные устройства, но не для RouterOS. Туда бы Linux полноценный портировать (сейчас идет работа в OpenWRT) и запустить polling-driven роутер (типа DPDK). Из текущих преимуществ: -компактность -отличное железо Недостатки: -софт -мало оперативки в младших моделях Если портируют базовый Linux c сетевым драйверами на него, то тогда я им займусь уже конкретней. Пока у меня немного другой проект. Честно сказать - при правильном софте он может дать легко фору всяким ISR4000 (если рассматривать только Ethernet) в чистую. Тут ISR будет хорош тем (если не смотреть на софт) что есть 24/7 Cisco поддержка (что аргумент весомый) и мультипротокольность. Но, господа форумчане, лично я не вижу смысла в xDSL/T1/T3 сегодня. Реально не вижу. Мультипротокольники вымирают и, наверное, это к лучшему. Можете еще некоторые помнят ад с X.25 и не менее неадекватный Frame Relay. Может в США - еще где-то там да, там ужасно старый коммуникации есть (да-да, господа, есть), где-то в сраных ?б?ях Японии на Хоккайдо - может быть, в Европе - не нужно уже как 10 лет. Мое мнение - будущее за такими архитектурами и такими софт-роутерами, но не за Mikrotik CCR.

на уровне чипсета-то оно может и реализовано, но в софте - нет, и техподдержка как таковая в принципе отстутствует (жалобы о неработоспособности/неправильной работе фичи никого не интересуют). из основного - нет igmp snooping, stp, loop detect, option 82/qinq в железе. т.е. - по факту получаете вебсмарт + сохо роутер 2в1. для офиса - пойдет, но не более. Полностью согласен. Если даже коммутатора позволяет реализовать описанный выше функционал, то вы его все-равно не получите из-за отсутствия программной обвязки. Говоря просты языком - не имеет смысла до того, пока его хоть немного допилят программно. Честно сказать, анализируя всю информацию о составе продукта, могу заявить что многий указанный выше функционал будет очень сложно реализовать на чипе этой серии коммутаторов.

Возможности их чипов коммутации крайне ограничены. Не реализовано НА УРОВНЕ ЧИПА КОММУТАТОРА: -DHCP/DHCPv6 Snooping -ARP inspection/port security -Link aggregation -NDP snooping/inspection -IGMP snooping -STP/RSTP/... и многое другое Можно конечно что-то на CPU сделать, но это будет ужасно медленно! Не советую. Если хотите информацию о их настройке: http://wiki.mikrotik.com/wiki/Manual:CRS_features Итог: толку от них мало. Сейчас это что-то похожее на очень слабые L2-коммутаторы, что не оправдывает их цены.

Можешь и напрямую: я когда-то так делал на RB450G. Забекапь лицуху только в самом начале... Вы имеете ввиду установить openwrt взамен routeros? Да, такое малой кровью возможно для этих моделей плат (роутеров) Mikrotik. stg живет в git года так с 2010: commit 641204dfbdb9fc870cdd2e7f9e3169a44693e7bf Author: Maxim Mamontov <****@gmail.com> Date: Sun Nov 7 11:20:26 2010 +0200 Добавление исходников Нашел, спасибо. Извините.

Можешь и напрямую: я когда-то так делал на RB450G. Забекапь лицуху только в самом начале...

А о кросс-компиляции здесь никто не слышал. Смеюсь с топика. Серьезные люди не могут откомпилить через кросс-компилятор. По свободе сделаю для вас сборочный пакет для OpenWRT. Может и получится его пропихнуть в основное дерево пакетов. Большая просьба разработчикам (madf) перенести репозиторий на git - на дворе уже 2016 год все-таки!

Что у вас clocksource? Смотрите инструкцию https://access.redhat.com/solutions/18627

В проекте НКРСИ нет ничего связанного с понятиями качества и действительно хорошей метрологии. Инициатива НКРСИ, по моему мнению, направлена на поддержание крупных и неповоротливых компаний типа Укртелекома, от качества связи которых лично у меня начинается зеленая блевота. По моему, мнению наша правовая база давно отстала от понимания информационных технологий. Информационные технологии и цифровая связь, а также сеть, являются чем-то очень туманным в трактовке нынешних нормативно-правовых актов. Я не вижу юридической состоятельности в принятых проектах НКРСИ в силу отсутствия должной терминологической базы, а также из-за несвязности с метрологическими понятиями. На данном этапе, я не вижу другого выхода кроме создания законодательной инициативной группы от имени представителей Интернет-провайдеров (скорее всего на базе ИнАУ) для совместного влияния на законодательные процессы. В противном случае, мы рискуем получить большие проблемы.

1. Переделать firewall. Отправлять весь UDP и другой IP-трафик членов адрес-листа заблокированных на drop или reject с icmp сообщением, отправлять весь TCP трафик того же списка на reject c tcp-reset (RST). Действия reject и drop являются терминирующими, ставьте их перед действием accept доступа на ваш прокси. 2. После перезагрузки должен остаться supout.rif. Если его нет, то сделайте последовательность, что привел к краху и вручную получите файл http://wiki.mikrotik.com/wiki/Manual:Support_Output_File. Затем отправьте этот файл письмом в Mikrotik http://www.mikrotik.com/support.html . P.S. Баги RouterOS порой поражают. Система закрытая, весь багфикс лежит на производителе. Подумайте дважды прежде чем выбрать эту штуку.

UPD: ОПа нужно было слать еще в самом начале дискуссии. Я хотел бы, чтобы администрация создала свод правил относительно тем, которые НЕ МОГУТ подниматься в условиях данного форума. Как-то видеть здесь, среди людей которые сражаются за доступный и свободный Интернет, обсуждение способов занять очередь в пятницу желания нет. Мое личное мнение. Оценивайте как хотите. В обсуждении участвовать не буду по идеологическим причинам.

Суть моей текущей работы состоит в постоянном саморазвитии. Без этого нет меня.

Это не является гибким решением. Советую Вам GoBGP ( https://github.com/osrg/gobgp) для BGP сессий на RS и RR. Если нужно перелить RIB в FIB, то свяжите его с zebra (Quagga) ( https://github.com/osrg/gobgp/blob/master/docs/sources/zebra.md).

Cacti для всего?! MRTG? Мать моя женщина! Не насилуйте труп: на дворе почти 2016 год. Разделите вашу задачу на три части: 1. Сбор (читка и передача дальше) метрик поручите прекрасному collectd. Он умеет ТОЛЬКО собирать метрики с разных источников и отсылать их в удобном формате кому-то: на всякие HTTP-службы, Graphite, RRD, RRDCached, InfluxDB, другой collectd, а также на - другие программы с поддержкой протокола collectd см. https://collectd.org/wiki/index.php/Binary_protocol . 2. Хранение метрик поручить либо RRD либо InfluxDB. RRD - хорош, быстр да и уже давно стандарт, но не обладает гибкостью. Если Вы хотите не просто графики рисовать, но как-то произвольно анализировать наборы стат. данных, то вам на InfluxDB. Да, издержки на IO у него повыше, но его возможности стоят того. 3. Визуализация. Я думаю, что тут все очевидно. Есть RRDGraph и прямые ручки, есть CGraphz (полное дерьмо, если честно между нами и по секрету), Cacti как вариант - только для визуализации (читай http://forums.cacti.net/about28169.html) Чтобы получать визуально данные из InfluxDB советую Grafana. Там необходимо будет запросами доводить графики до себя (читай матан и статистику). Такое разделение поможет Вам собрать схему которая Вам нужна. Если у Вас будет очень большая сеть, то вы сможете разнести сбор и хранение и обработку метрик на разные узлы, что намного лучше вашей некросхемы "все-в-одном". Graphite не советую: он жестко вешает систему в IO-wait при использовании HDD. И фу-фу-фу Python, на который я сквозь пальцы смотрю, ибо crap для серьезных нагрузок.

dmesg и mount - это логично уже ведь после установки... А я пытаюсь скормить ему флешку в режиме диалогового окна, типа: "системе не удалось найти пакет bnx2\бла-бла_бла.бла.бла.2.fw. Возможно он есть у вас на съемном носителе. Хотите установить пакет со съемного носителя? да\нет " И вот он вопрос: Нет тут ни dmesg ни mount... тут есть "да\нет" и поидее должен быть втулен какой-то съемный носитель, который схавает Debian не пережовывая команды... Ок, тулим флешку, жмем да... думает... (нет там диалога, некуда печатать!), и опять этот же самый вопрос... Остается лишь нажать "Нет" и идти далее, а после загрузки системы, скармливать ему эту флешку со всеми дмесгами и маунтами. Так? Или ЕСТЬ все-таки вариант как-то на этом вопросе системы - ткнуть ей в нос этот пакет с "сменного носителя" ? - (чтоб оно молча прожевало.) Ну неужели и ежу не ясно, что если во время установки, то нужно распаковать содержимое подпапки /lib/firmware пакета в корень флешки. Если после - тупо установить пакеты. Там же написан путь, где оно должно лежать. Ставьте систему, а затем уже ставьте пакет с последующей доустановкой всего необходимого ПО.

нет, можно обыкновенный fat32 закиньте туда файлик http://ftp.pl.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-bnx2_0.43~bpo70+1_all.deb примонтируйте флешку через mount и установите через dpkg -i пакет После - перегрузитесь и пробуйте снова.