Negator

У нас Микротик обычно это L3 аггрегатор. Роутер для клиентов. Ну и всякий MPLS. Шейпим на отдельном сервере. DHCP -тоже на отдельном центральном. VLAN на клиента мы не делаем в PON обычно. Достаточно влана на PON порт. И вот уже вланов вместо 3к получается пару десятков. У нас пока нет тысяч абонентов на PON, есть только узлы с несколькими сотнями. Все работает нормально. Еще есть отдельные микротики для целей NAT и только. Вообще соглашусь, что использовать Микротик как чистый L2 BRAS с шейпингом, очередями и прочей авторизацией не есть правильно

Уже много лет используем в офисе welltime https://www.welltime.ru/ как купили - так и работает.

Выдавать IP адреса по DHCP самим микротиком - идея так себе. По DHCP серверу в каждый влан это плохо на мой взгляд. А вот использовать стороннее решение и DHCP-relay - вполне. И все это замечательно автоматизируется. Создать кучу вланов на микротике проблем не вижу. Да возможно при ребутах могут быть проблемы. Но вы часто ребутаете условные брасы? У нас вон годами без ребута стоят, жужжат и не жалуются. Хотя делать вот прям большой L2 брас на микротике я бы не стал. А как районнные L3 аггрегаторы использовать микротик - вполне себе решение.

Сколько себя помню -такой вопрос поднимается всегда. Сколько видел провайдеров - у всех свои костыли. И несколько систем. Многие пилят свое, но это не всегда помогает решить все проблемы. Сами пользуем самописное решение. Часть проблем там решена, но далеко не все указанные автором. На мой взгляд единого решения нет и не может быть, каждый работает так, как удобно ему.

не обязательно. Есть куча способов выдавать адрес. Например по номеру влана. Если новых то наверное да.

А кто то еще не ушел с PPPoE? Блин, народ, 2024 год на носу, а вы все мучаете и себя и техподдержку и свое оборудование и клиентское туннелями? Переключили на IPOE, забыли о проблемах как страшном сне и сократили техподдержку наверное раза в 3. Еще много лет назад.

Видимо не очень срочно. Договорились, обещали связаться и молчок.

Если мне не изменяет память то вот что то такое было и лечилось https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00048622en_us

Привет. Отписал личкой. Могу помочь.

Знаешь, иногда его подход работает и мысли вполне здравые. Микротик вполне себе железка удобная для многих целей. У нас на них часто удаленные узлы работают, в центре крутится NAT на 6-10 Гбит каждый. Тут говорят - можно линукс поставить. Да можно. Но не всегда и не везде это удобно. И да - иногда лучше и правильнее вывести что то на отдельные железки. Тот же NAT например.

В акцесс не всегда удобно. Часто с этим проблемы. Я не утверждаю что первый вариант работать не будет, конечно будет и никаких проблем не доставит. Так, мелкие неудобства. Но чисто из за соображений удобства выбрал бы второй.

Вот вам ситуация наоборот. Перекопал где то трактор кабель. Восстановить быстро возможности нет. Зато реально взять L2 канал у партнера, у соседа, да хоть у черта лысого. Но. В первом случае вам надо будет брать именно нужный вам VLAN или что то придумывать. Во втором - согласовал любой влан с любым партнером - настроил OSPF, получил рабочий канал. И весь домен тягать к соседу не надо. А можно и заранее резерв сделать через кого то до нужной точки. Второй вариант универсальнее и удобнее на мой взгляд.

Работать будет и так и так. Броадкастовый домен на 30 точек -смешно. Мультикаста там тоже кот наплакал. Можно всякие traffic control настроить от флуда на всякий случай. Но я бы выбрал вторую схему. По мне это удобнее и для расширения тоже например. Или вдруг какие резервы захотите сделать. Отдельными вланами все это делать удобнее. 30 вланов экономить - ну такое, не особо сэкономишь. IP линковочные вообще серые - чего их экономить.

это на обычном hex 150 eoip и vlan ?

Я наоборот вланы пихаю в EOIP каналы. И внутри все с тегом. Для меня так логичнее. А чаще в VPLS, VPLS быстрее Ну и далее по 2 варианту.

По нашей практике они достаточно надежны.

веб то зачем? Так то настраивал эти железки и даже автоматизировал. Но в веб не лазил.

1. Самый лучший вариант это L3 и OSPF 2. Гонять STP по операторскому арендованному влану - не есть правильно. И я уверен что там BPDU заблокированы, поэтому у вас и наблюдаются проблемы. Можно поднять EOIP или vpls поверх влана, проблемы решаться, но надо следить за MTU или попросить повышенный у оператора. 3. Вместо RSTP можно рассмотреть bonding двух EOIP туннелей. P.S. и учтите, что все это делается процессором железки, мелкие слабые микротики не вытянут гигабит

Если актуально - напишите и мне подробности. Кое какой опыт имею, в том числе в разработке биллинга.

Провайдинг нынче это не про деньги. Тем более с нуля. А если в городе есть 2-3 конкурента, то скорее всего вообще бессмысленное занятие. Нужен как минимум хороший админресурс. Если за пару лет получится отбить хотя бы 5% абонентов от крупных операторов -будет хорошо. Подумайте стоит ли оно того. Для начала работы достаточно пары тройки микротиков в узел. 1009 или что то подобное. Несколько сотен абонентов оно спокойно вытянет, да и потом в случае модернизации и расширения пригодятся. Биллинга как такового не нужно на первое время. Ну и коммутаторы, оптика и все прочее. Настраивать все вручную. Через полгодика станет понятно что и как делать. Сейчас все равно все это не просчитаешь. Затраты на все эти железки минимальны по сравнению с остальными затратами. Ищите сразу юрлиц, физики либо убыточны, либо находятся на грани рентабельности, а возни с ними много. Ну и конечно всякие лицензии, СОРМ, Яровая и прочее прям сходу вгонят в убытки. Я бы на вашем месте попробовал поискать кого либо и поработать по агентской схеме.

Возможных вариантов схем слишком много. А вводных от вас слишком мало. Непонятно какие сервера доступа, какое оборудование, хотя бы вчерне схему сети. Можно сделать QinQ, можно обойтись без этого. Много сетей и различных мнений. QinQ и влан на абонента обычно делают для того, чтобы тянуть всех абонентов в центр по L2 Но это не всегда удобно, иногда логичнее не тянуть абонентов с удаленных узлов до центра. Мне лично больше нравится L3 схема. Резервирование серверов тоже можно сделать по разному. В общем - больше конкретики. Попробуем что то предложить.

DES 3526 был отличный свич, но время его ушло. Срок службы у живых железок давно пришел к концу. Если еще где то и работает - то это везение. Я бы не стал собирать mstp на разных вендорах. Упрощайте схему.

Мы мониторим статусы портов ну и какой порт является рутом. Но это на длинках в кольце. На циске наверняка можно найти mib для этих целей и сделать шаблон для заббикса.

Конечно надо знать в каком порту какой абонент. А сделано это у вас в биллинге или еще где -мне неведомо. И да -информация должна быть актуальной.

То у вас влан на абонента, то порт абонента не знаете. Как такое вообще возможно в наше время не понимаю. А касаемо влан на абонента - схема хорошая, о применима далеко не всегда.