[LostSoul]

2 минуты назад, Saab95 сказал:

микротик выпустит еще линейку устройств с еще более быстрыми процессорами

судя по всему , не выпустит никогда.

так как во первых конкуренция.

А вот вторых - если мне сегодня чтоб прожевать 100мб надо покупать железку с SFP+  , то тут видно только одно - вы предлагаете использовать микротики противоестественным способом.

Более вероятно, что микротик наконец допилит  нормально 82 опцию и.т.п.   в своих коммутаторах, "как у всех".

и тогда именно этот вариант вы и будете советовать.

 

 

 

 

6 минут назад, Saab95 сказал:

Все равно нужно некое устройство, которое соберет каналы от абонентов и даст им интернет.

в случае, если фильтрация всего возможного мусора уже выполнена на access то это тоже может быть аппаратная железка с весьма скромным CPU и относительно низким ценником.

Микротик предпринял весьма неудачную попытку собрать 36-72 ядер в одну коробку и в теперь пытаетесь подвести под эту мутацию модель использования.

А у других эти "36 ядер" стоят по устройствам доступа.

 

[Saab95]

7 минут назад, LostSoul сказал:

Более вероятно, что микротик наконец допилит  нормально 82 опцию и.т.п.   в своих коммутаторах, "как у всех".

и тогда именно этот вариант вы и будете советовать.

Про эту опцию были упоминания на этом форуме еще очень давно, что от нее надо всячески уходить, т.к. было много тем, не только на коммутаторах, но и на поне, где с этой опцией постоянно были проблемы, их решали и решали.

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

 

С коммутаторами то же. Что, сейчас все поддерживают QinQ, вариант собрать на каждом коммутаторе все влан на порт, на промежуточном коммутаторе запаковать все в транспортный влан и подать в центр, где уже обработать?

 

А как быть с вариантом, когда абонент хочет в одном порту и интернет, и канал на свой соседний офис, как это сделать с 82 опцией без дополнительных телодвижений?

 

10 минут назад, LostSoul сказал:

Микротик предпринял весьма неудачную попытку собрать 36-72 ядер в одну коробку и в теперь пытаетесь подвести под эту мутацию модель использования.

Просто надо правильно его использовать, и ставить там, где он нужен. Кроме всего есть отличная железка с 16 ядрами и оптическими портами, которая играючи собирает магистральные каналы и передает их в центр по 10Г порту. Аналогов ей при своей цене и функционалу особых нет.

[LostSoul]

6 минут назад, Saab95 сказал:

Другой вариант это сделать 82 опцию и постоянно удивляться, что же вот работало и начало глючить, или вот работало, обновили прошивку и началось.

ничего подобного не происходит.

проблемы бывало вылезали в связи с изменением в работе клиентских ос.

когда в связи изменением работы dhcp в windows пришлось всякие там zeroip добавить в прошивку

но они в этом случае и на вашем bras вылезли бы

 

[vurd]

19 часов назад, LostSoul сказал:

есть куча вариантов резервирования L3 шлюза и без виртуализации.  всякие vrrp и аналогичные.

 

Вот именно. Поэтому с резервированием "л3 коннектед" схем вопросов не возникает.

Меня интересует как делать резерв в vlan-per-user, когда у вас qinq до браса. Это идеально с точки зрения управления услугами абонента, но я вообще не вижу схем, как динамически добавлять брасы, да еще и с фейловером. Т.е. я понимаю как сделать резерв самого л2 канала с агрегации до браса, тут mpls/erps, в зависимости от возможностей, но что делать с брасами.

[vurd]

17 часов назад, Saab95 сказал:

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

 

хз. пять лет использую тот же элтекс ваш любимый с опт82. как пол lte-8st написали для нас опт82, так она и до сих пор в актуальных моделях и работает. при каждом обновлении ничего не ломалось. было один раз, когда еще два формата опции добавили, оч давно.

но тут я согласен, vpu будет лучше, так как на элтексе конкретно криво работает dhcp snooping

[zhenya`]

26 минут назад, vurd сказал:

Вот именно. Поэтому с резервированием "л3 коннектед" схем вопросов не возникает.

Меня интересует как делать резерв в vlan-per-user, когда у вас qinq до браса. Это идеально с точки зрения управления услугами абонента, но я вообще не вижу схем, как динамически добавлять брасы, да еще и с фейловером. Т.е. я понимаю как сделать резерв самого л2 канала с агрегации до браса, тут mpls/erps, в зависимости от возможностей, но что делать с брасами.

ASR9k SRG

на хуавеях ME еще есть что-то типа VRRP для l2connected ipoe.

 

[Saab95]

В 02.03.2019 в 15:25, LostSoul сказал:

ничего подобного не происходит.

проблемы бывало вылезали в связи с изменением в работе клиентских ос.

Ну а дальше то что? Вот как вы видите свою сеть и то, что используете, скажем через 5 лет? Будете продолжать L2 везде использовать?

Мы, вон, еще во времена радиосети, перейдя на L3 транспорт получили конкурентное преимущество над всеми другими беспроводными операторами, потому что могли все резервировать как угодно, а они были L2 схемами и STP ограничены.

[LostSoul]

33 минуты назад, Saab95 сказал:

Будете продолжать L2 везде использовать?

Вы точно так же используете L2.  ( /24 маску у клиентов )

То что вам приходится это L2 с фильтрацией настраивать на микротках методом "через жопу", обманывая маршрутизатор о сути происходящего ,  не делает его L3.

Как будет выглядеть моя сеть через 5 лет, боюсь в большей степени определит яровая и "суверенный интернет" , чем моё желание.

возможно что vlan-per-user станет суровой необходимостью в целях СОРМирования локального трафика , а вовсе не потому что мое мнение кого-то волнует.

 

 

 

[maxkst]

В 02.03.2019 в 23:15, vurd сказал:

но я вообще не вижу схем, как динамически добавлять брасы, да еще и с фейловером

присоединяюсь к вопросу. есть идеи, кроме VRRP?

[pppoetest]

В 01.03.2019 в 03:01, LostSoul сказал:

в дизайне c IP MAC Binding обычно трафик между внутренними абонентами безлимитный.

А сормировать как?

 

В 04.03.2019 в 17:47, LostSoul сказал:

возможно что vlan-per-user станет суровой необходимостью в целях СОРМирования локального трафика , а вовсе не потому что мое мнение кого-то волнует.

Я к тому и клоню.

[maxkst]

26 минут назад, pppoetest сказал:

Я к тому и клоню.

Вланы тянуть на оба браса? или они не ломаются?

[LostSoul]

40 минут назад, maxkst сказал:

Вланы тянуть на оба браса? или они не ломаются?

эта схема ничем не хуже другой в плане резервирования.

и для балансировки тоже подойдет ( виртуальный мак и 2 BRAS )

если один сломался - все шлюзы поднимаются на оставшемся

 

 

[maxkst]

И PUBLIC IPs анонсируются в OSPF с резервного? Что за фишка виртуальный мак? на Микротиках есть такое? VRRP?

 

 

5 минут назад, LostSoul сказал:

виртуальный мак

DHCP сервер на нём?

[LostSoul]

6 минут назад, maxkst сказал:

И PUBLIC IPs анонсируются в OSPF с резервного? Что за фишка виртуальный мак? на Микротиках есть такое? VRRP?

 

типа такого.

не знаю, на микротиках не приходило в голову такое делать за ненадобностью.

ospf можно не использовать вообще

bgp + bfd

те адреса что при нормальной жизни ходят через первый бордер - с него с большим bgp med , с второго с меньшим  bgp med

 

 

6 минут назад, maxkst сказал:

 

 

 

DHCP сервер на нём?

я не обдумывал как это сделать на микротиках.

делали это на больших bras на x86  с кучей ядер и несколькими 10г сетевухами.

лет 15 назад.

 

[maxkst]

@LostSoul Ну так мы же в ветке Микротика, зачем тут предлагать несуществующие решения?

[LostSoul]

1 минуту назад, maxkst сказал:

@LostSoul Ну так мы же в ветке Микротика, зачем тут предлагать несуществующие решения?

да я не смотрю в какой мы ветке. Я сюда через "непрочитанные сообщения" попадаю

А сама идея крупного BRAS на микротик настолько утопична, что сие даже не приходит в голову , при обсуждении кем-то кроме Sabb95

 

[maxkst]

1 минуту назад, LostSoul сказал:

А сама идея крупного BRAS на микротик настолько утопична, что сие даже не приходит в голову , при обсуждении кем-то кроме Sabb95

Ну это вам так кажется

[Saab95]

Если терминацию абонентов делать на устройствах, к которым они подключены, или на промежуточных узлах, то никаких острых вопросов резервирования уже нет - пока кто-то анонсирует нулевой маршрут в сеть, туда данные и побегут. Никто не мешает пустить 2 и более таких анонсах в разных частях сети, тогда кто к кому ближе, те туда и будут данные отправлять. Все просто и не нужно никаких костылей.

[alibek]

45 минут назад, Saab95 сказал:

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

Это от природы такой навык — когда задают неудобный вопрос, начало ответа начать с его повторения, а затем продолжить ответом на совершенно другой вопрос? Или на курсах Микротика ему обучают?

Речь не про резервирование транспорта, а про резервирование BRAS.

[myst]

В 28.02.2019 в 18:47, LostSoul сказал:

Но даже на том оборудовании где такого нету, можно через ACL запретить все DCHP ответы  , исходящие  с абонентских портов.

 

 

есть вполне рабочая в нищие времена технология, по исчерпанию пула левого DHCP.

стоит в центре демон в 50 строк на перле, выжирает весь пулл и переодически просит ещё :-)

 

посмотрел на календарь, действительно, 19й год на дворе...

[LostSoul]

2 часа назад, myst сказал:

посмотрел на календарь, действительно, 19й год на дворе...

Ну то есть раз 19  , надо было покривить душой и сказать что "если у вас неуправляемые коммутаторы ( вдруг ) , то только пойти вздернутся?

 

[myst]

2 часа назад, LostSoul сказал:

Ну то есть раз 19  , надо было покривить душой и сказать что "если у вас неуправляемые коммутаторы ( вдруг ) , то только пойти вздернутся?

 

мысль верная... можно ещё утопиться. особенно если вглянуть на рынок бу упрявляшки... там ценник ниже плинтуса. иначе начинается вот такой плачь ярославны и подгорание пуканов от левых дхцп, непонятных глюков без возможности диагностирования итд.

 

[LostSoul]

Только что, myst сказал:

непонятных глюков без возможности диагностирования итд.

для возможности диагностирования "непонятных глюков" совершенно недостаточно купить "управляшки".

Там требуется еще и "думать" в минимальном количестве.

Вы мало видели в организациях управляшек , которые никто никогда не настраивал?

И так и списывают спустя много лет ни разу не настроенные

 

 

[myst]

1 минуту назад, LostSoul сказал:

для возможности диагностирования "непонятных глюков" совершенно недостаточно купить "управляшки".

Там требуется еще и "думать" в минимальном количестве.

Вы мало видели в организациях управляшек , которые никто никогда не настраивал?

И так и списывают спустя много лет ни разу не настроенные

 

 

ну это уже совсем другой вопрос... диагностировать неуправляему сеть можно только выдергивая кабеля. других инструментов тупо НЕТ. в управляемой сети инструменты ЕСТЬ и уже ваше дело пользоваться ими или нет.

[LostSoul]

1 минуту назад, myst сказал:

других инструментов тупо НЕТ.

если вам завезли думать, то инструментов для исследования всегда много.

попробуйте пообщаться с талантливыми админами тех лет, когда ничего кроме мыльниц не было и строить было еще просто не на чем.