taf_321

Во вновь строящихся сегментах qinq, в старых еще не модернизированных и на радиолинках pppoe. v6 обоих случаях просто работает.

Вы уже нашли ответ на свой вопрос, осталось только с ним смириться. И таки принять тот факт, что сеть строилась по кривому дизайну и сейчас вы пожинаете плоды этого дизайна. Им и не нужно этих перспектив видеть. Продавать v6 допом это жлобство. v6 это возможность оказывать услугу в будущем. Кстати, ради интереса прошелся тут по тому, что же присылает РКН, и таки что наблюдается: rkn=# select count(ip) from zap2_ips where ip > inet '255.255.255.255'; count -------- 678298 (1 строка) rkn=# select count(ip) from zap2_ips where ip < inet '255.255.255.255'; count --------- 1084129 (1 строка) rkn=# Как бы ~62% ресурсов в интернет помимо v4 адреса имеет еще и v6. Так что ныть про "нет ресурсов на v6" как бы уже поздно, и даже вредно.

Да все с вами понятно. построили сеть из говна и палок, как итог сеть не имеет потенциала на развитие. Тут к гадалке не ходи, виноват ipv6, кто бы сомневался.

Фильтровать L3/L4 на железе, не предназначенном для этого... Как бы так сказать-то... В общем, ССЗБ.

Абаждите, не спешите. Я что-то пропустил, и v6 опустился до L2 и подменяет собой Ethernet-кадр? Так-то всем этим мегафичам cut-through и fast-forward всего и надо, это SRCMAC-DSTMAC и они могут спокойненько лить ваши джамбо-фреймы хоть по 100М размером. И похрену что там внутри - v4 или v6, на концах получатель с отправителем сами пусть разбираются что там и кому. Или таки вы на такой коммутатор возлагаете функцию маршрутизатора? Но тогда получается, что на основании применения вами неправильного инструмента в неподходящем окружении вы выводите приговор всей технологии в целом.

При правильной реализации клиентского подключения, вопросы с нарезкой скорости и NAT совершенно перпендикулярны даже в рамках реализации в одном устройстве. Современное серверное железо позволяет поднимать NAT с полосой 10G+10G на стандартных системных инструментах.

В свое время, когда были идея запилить v6-only перепробовали NAT64 в разных реализациях. В итоге пришли в Dualstack. Очень уж с NAT64 много гемора как в плане трансляции, так и обработки DNS запросов.

На данный момент проблем с памятью нет. Естественно с железом возрастом младше десяти лет. Про найденное на помойках мамонтовое говно смысла говорить нет. Оплатит тот, кто из сиюминутной выгоды купил этот хлам на вторичке. У меня большие сомнения, что у вас все работает на том, что вы поставили новым двадцать лет назад. Ибо ни разу таких не попадалось. А вот всяких умников, ставивших древний хлам с ебея у нас тут полный форум. И да, для них одна надежда, что на помойки вдруг массово попрут выкидывать железо с новыми фичами.

Я и говорю, у них судьба такая - страдать. Опять же, кто им доктор, если они отрывают рабочую подсистему? Сейчас прошелся по наличным установкам, выводок IPBX'ов на основе центоси - есть v6, сама центось - есть из коробки, бубунта, дебиан и их производные - есть. oracle linux - есть. Винда начиная с XP - есть. Все телефоны-планшеты - в наличии. Приставки на базе ведроида - есть. Я выше написал, у нас v6 десять лет уже раздается. Проблем с v6 нет. Поначалу еще были жалобы на ютуб, которые можно было привязать к v6 по причине отсутствия его на ближайших GGC, но уже лет семь как все GGC на которые кидает нашу сеть с поднятым v6. А нахрена для iptv мультикаста v6??? Не нужно упарываться настолько. Есть влан для интернета с v4/v6, есть влан для iptv с православным v4 мультикастом. Все довольны, никто никому не мешает. Опять же, по причине массового использования носимых гаджетов и злое...чей практики подключения смартТВ и ТВ приставок по WiFi гонять ТВ по мультикасту по wifi это отдельный вид мазохизма. Потому тв по мультикасту у нас нигде не прижился, даже в PON.

Да, accel-ppp выступает DHCPv4/DHCPv6 сервером, и по получению Req шлет запросы на радиус.

Обработка броадкаста 33:33:00:XX:XX:XX в обед триста лет, его даже говнодлинки DES-1008 понимали.

По каким помойкам надо копаться, чтобы таки железки найти? Или вы до сих пор клиентам предлагаете DIR-300 при подключении? Из актуального оборудования, выпускаемого в последние 10 лет v6 поддерживается. Каким образом L2 оборудование должно влиять на L3? Все понятно с теми, кто повелся на разводилово opt82, они должны страдать всегда ибо это их выбор, но кто голову включал при проектировании, им-то как свитчи помешать должны? Все как раз наоборот - решения на тазах v6 поддерживают с момента рождения (не считая теминальных случаях брасов на mpd5, netgraph и нативного pppd), это с железными решениями могут вылезти совершенно неожиданные нюансы. Владельцам BRAS от Ericsson и Lucent - привет! Раздавать v4/v6 дуалстеком не то что не сильно дороже, оно вообще никак не влияет. Настройка v6 инфраструктуры от поднятия пиров с аплинками до настройки всего промежуточного своего оборудования делается один раз, настройка радиуса, чтобы он назначал v6 тоже делается один раз. Да, могут возникнуть проблемы со стыковкой с биллингом, но это проблема конкретного пользователя конкретного биллинга (возможно что даже конкретной версии биллинга). И да, упарываться в экстремизм с переводом всего и вся у себя на v6 идея не самая умные. Дуалстек тем и хорош, что свои сервисы оставлять на старой адресации, разве что научить локальный кэширующий рекурсор отвечать по v6. Раздаем v6 дуалстеком с 2012 года, у кого поддерживается, у тех обе адресации, у кого не поддерживается - только v4. Сейчас _все_ оборудование с автоматическим получением адреса умеет в v6. Доля v6 трафика у нас сейчас колеблется от 15 до 20%. До блокировки пейсбученьки и сиськаграммчека доходило до трети. И то, что они работают по v6 из клиентов никто и не подозревает.

Файл != ключ.

Файл генерится при старте. По-идее в дистрибутиве, да и в исходниках, есть обвязка по работе с этими ключами.

server: verbosity: 1 statistics-interval: 3600 statistics-cumulative: yes num-threads: 4 interface: IP_ADDR_V4 interface: IP_ADDR_V6 outgoing-interface: IP_ADDR_V4 outgoing-interface: IP_ADDR_V6 outgoing-range: 8192 so-rcvbuf: 4m so-sndbuf: 4m so-reuseport: yes edns-buffer-size: 1232 max-udp-size: 1400 msg-cache-size: 50m num-queries-per-thread: 1024 rrset-cache-size: 100m rrset-cache-slabs: 4 cache-min-ttl: 3600 infra-cache-slabs: 4 do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: NET/LEN allow access-control: ::0/0 refuse access-control: ::1 allow access-control: ::ffff:127.0.0.1 allow access-control: NET6/LEN allow root-hints: "/root-cheburnet.hints" hide-identity: yes hide-version: yes qname-minimisation: yes qname-minimisation-strict: no prefetch: yes rrset-roundrobin: yes minimal-responses: no auto-trust-anchor-file: "/var/lib/unbound/root.key" key-cache-slabs: 4 unblock-lan-zones: yes ratelimit-slabs: 4 ip-ratelimit-size: 4m ip-ratelimit-slabs: 4 remote-control: control-enable: yes control-interface: 127.0.0.1 control-interface: ::1

Конкретно CX3 реализация работы с VLAN сделана на отъ....сь, вроде как есть и даже работает, но отвалится может на ровном месте. У меня такая карта выстрелила аппаратным лимитом в 128 VLAN'ов.

На удивление, автоматизировать добавление ONT в хуавее не сложно, а вот удаление это та еще эквилибристика с вылавливанием и очисткой сервисных портов по всяким iptv заморокам. На базе вот этого https://github.com/explicitnull/h-ont-activator нарисовал под себя добавлялку, а вот удаление проще оказалось делать через фирменный NMS U2000

Рулится оно там на роутерах откровенно хреново. Может для домашней сетки на два-три влана это все подходит, но для организации именно транзитного пропуска вланов что есть в OWRT это полная лажа.

Но любим-то мы свитчи не за это. Что у решения на OWRT именно с L2? Ну, там, vlan'ы тегированные не тегированные, в какой STP они умеют, что на тему Loopdetect, как с LACP, умеют ли в диагностику L1, что там со снятием статистики по SNMP, и сколько оно без перезагрузки может работать. Как этим всем управлять (волшебные грибы закончились еще в процессе освоения настройки vlan'ов в самых первых микротиковских свитчах на тогдашней SwitchOS).

Есть форк зимбры 9-й - https://www.zextras.com/ru/carbonio-community-edition/ Сами сидим на зимбре 8.8.15 с последними патчами. Головняк был всего один раз, когда встала надобность миграции с 32-битной архитектуры на 64-битную 10 лет назад. И да, поначалу на пустой базе спама может приходить больше, но кнопка "Спам" помогает. С какого-то момента даже всеми любимые "Notice of Claimed Infringement - Case ID" начинают отлетать в папку "Спам" автоматом.

У нас эквайринг сделан через yoomoney, у них есть SDK на базе которого уже прислюнявлено зачисление через utm5_payment_tool

Проблема с NUMA никуда не денется на любой архитектуре.

Таблица хранится в одном месте, и в многопроцессорных системах обращение к ней из другой NUMA будет связано с соответствующими накладными расходами. Там же еще будет веселье, когда данные надо перекидывать с сетевухи на одном процессоре на сетевуху на другом процессоре, тут все ништяки от больших процессорных кэшей пойдут гулять лесом. Потому для маршрутизаторов и BRAS оптимальнее ставить однопроцессорные сервера. И уже в рамках одного процессора выбирать баланс между количеством ядер/размерами кэшей/частоте.

Да. Реализованы на nftables

Как были тазики с accel-ppp, так и остались.