flif

на микроте /31 делается вот так: /ip address add address=10.50.50.10/32 network=10.50.50.11 interface=vlan_555 на другом конце, на котором оборудование умеет /31: 10.50.50.11/31 Ну и ещё можно лайвхаки там всякие юзать благодаря этой реализации, например для для ip unnumbered: /interface vlan add name=vlan_100 interface=sfpp1 arp=proxy-arp comment="unnumbered_user1" add name=vlan_101 interface=sfpp1 arp=proxy-arp comment="unnumbered_user2" add name=vlan_102 interface=sfpp1 arp=proxy-arp comment="unnumbered_user3" /ip address add address=10.50.50.1/32 network=10.50.50.100 interface=vlan_100 comment="unnumbered_user1" add address=10.50.50.1/32 network=10.50.50.101 interface=vlan_101 comment="unnumbered_user2" add address=10.50.50.1/32 network=10.50.50.102 interface=vlan_102 comment="unnumbered_user3" Ну а на стороне каждого из клиентов это будет ip: 10.50.50.X mask: 255.255.255.0 gw: 10.50.50.1 и да, это будет работать даже если клиент укажет себе неверно адрес шлюза А если прикрутить сюдой DHCP со скриптом создания такой записи на интерфейсе - то вообще почти Erricsson получается для небольших узлов или вцелом компаний - очень даже очень)))

используйте /ip route rules можно управление сделать и при помощи /ip firewall mangle, но вариант через firewall жрёт ресурсы cpu сильно больше. вот тут есть packet flow mikrotik: https://www.mikrotik-trainings.com/trainings_files/docs/PacketFlowV6wIPSec.pdf решение о том через какой интерфейс отправлять ответные пакеты принимается в routing decision, а по диаграмме это сразу после local process. В общем правило будет выглядить примерно так: /ip route add gateway=<isp1_gw> routing-mark=<table_name> /ip route rules add src-address=<ip_from_isp1> action=lookup table=<table_name> если нужно чтоб публик ип отвечал с внутренних сетей, то добавляем как в фаерволе правило повыше: /ip route rules add src-address=<ip_from_isp1> dst-address=<internal_network> action=lookup table=main

Ну так вы используйте железки по назанчению. Бордер c БГП должен быть в режиме fastpath, нат в fasttrack на establ/related/untrack, BRAS отдельная железка. Микротики прямым текстом, как и другие производители, пишут в вики что "ЧУВАКИ, НЕ ЮЗАЙТЕ КОНТРЭК ОДНОВРЕМЕННО С FV!!!!!" Если серьёзно, то бордер на линкусе/фряхе неплохая штука, однако это решение требует постоянной поддержки, если что то неожиданно накернулось - нужен весьма недешёвый спец для того что бы воскресить, которому надо ежемесячно платить. Как итог, компании выгоднее купить пачку микротиков(ибо дишман, и спеца обучить стоит недорого, и найти готового несложно). К тому же ни одна шайтан балалайка на берде/кваге не даст того удобства управления, которым обладает микротик, той простоты и гибкости настройки различных фильтраций. К слову, у меня есть как минимум 4 маршрутизатора в сети, которые жуют весьма немало трафика, CCR1009 в роли внутреннего MPLS HUB жуёт 5Гбит, CCR1016 в роли бордера с 4 FV жуёт спокойно 8 Гбит. А возможности торчить трафик на интерфейсе не раз спасали при детектировании DDoS. Главная жопа микротика - полисинг абонентов, чем больше правил simple queue - тем менее он производительный. Касательно БГП есть отдельная боль, но когда речь идёт о том что бы зарабатывать бабло, а не транжирить на дорогущих специалистов - Микротик для маленьких операторов это палочка выручалочка. В роли ната, без FV тот же CCR1036 с двумя SFP+ за весьма бюджетный ценник порвёт жопу многим вендорам, в соотношении цена/производительность. А уж если вы выросли из микротика, и хотелось бы всё таки начать продавать большие объёмы услуг с хорошим качеством то велком Juniper MX 80/204 (Border) + СКАТ(BRAS + NAT), это прям топчек сетап, у самого нет, но у коллег работает очень классно))))

Всем доброго времени суток, товарищи! Собственно думаем над заменой для Extreme x670-48x(V1), присматриваемся к следующим моделям от huawei: Huawei CloudEngine S6730-H48X6C - не можем найти в спецификациях сколько PPS он способен жевать(Коммутаторы типа CE6851 жуют 1080 милионов пакетов в секунду), и какой функционал отдельно лицинзируется(MPLS/ MPLS-TE,VPLS/ VXLAN), подскажите плез, мож я где пропускаю глазами. А так же не известен объём буфера портов. Huawei CloudEngine 6851-48s6q-hi: вроде всё есть, и производительность норм, но вобще нет официальных спецификаций на предмет лицензирования функционала. Huawei CloudEngine 6855-48s6q-hi: Чем отличается от 6851 вообще непонятно. Так же смотрели более новые CloudEngine 6857-48S6CQ-EI (32 мб буфер), CloudEngine 6870-48S6CQ-EI(4ГБ буфер), CloudEngine 6881-48S6CQ(42МБ буфер, вобще тёмная лошадка. Однако из последних линеек, коммутаторы стоят как золотые кони, при этом не намного производительнее старой линейки. Ну и напоследок, сталкивался ли кто нибудь из участников форума с моделями s6720-16x-li-16s-ac либо s6720-32x-li-32s-ac, размышляем над тем насколько они функциональны и что могут позволить. CloudEngine 6870-48S6CQ-EI

@maxkst Да,работает, но вызывает рандомные флапы VPLS. Не претендую на истинность что " надо добавлять loopback", однако методом проб и ошибок пришли к такому сценарию, те проблемы с которыми сталкивались - ушли. С чем были связанны проблемы? болт его знает, но это действие их решило))))

@maxkst loopback в данном случае нужен для задачи LSR ID и transport address. MPLS интерфейс - любой интерфейс участвующий в маршрутизации(PPTP/L2TP/GRE/EOIP/VLAN/Физический интерфейс/BRIDGE и так далее) MPLS interface mtu - ДОЛЖНО БЫТЬ ОДИНАКОВОЕ НА ПЛЕЧАХ, И НЕ МЕНЬШЕ ЧЕМ НА ПЛЕЧАХ на ТРАНЗИТЕ, в должно быть не больше чем максимальное L2MTU в транзите, задаётся глобально вот так: /mpls interface set numbers=0 mpls-mtu=1526 если надо отдельное для интерфейса задать: /mpls interface add mpls-mtu=1526 disabled=no interface=ether4 Для того что бы при выходе в интерфейс отрабатывал MPLS, маршрутизатору надо об этом сообщить, в частности крайне желательно добавлять loopback так же в этот список из за того что он является transport address, на PPP интерфейсах можно включить для всех относящихся к одному профилю в /ppp profile, делается это вот так: /mpls ldp interface add interface=loopback0 disabled=no /mpls ldp interface add interface=ether4 disabled=no При построении тоннеля нельзя использовать area range на транзитных маршрутизаторах Собственно VPLS туннель это однонаправленный туннель, он легко может быть Running с одной стороны, а с другой быть no running по причине несоответствия MPLS INTERFACE MTU на плечах или транзите.

Проверьте что бы MPLS INTERFACE MTU было на всём промежутке одинаковое, ну или что бы на плечах было одинаковое с обеих сторон, а в промежутке НЕ МЕНЬШЕ. Так же обязательным условием выступает что бы не использовался AREA RANGE при анонсировании маршрутной информации, в противном случае LDP не построится.

Спор о тёплом и мягком))) CCR это не коммутаторы, мне кажется люди сравнивающие их с cisco коммутаторами - имбицилы. Для особо тупых, у микротика есть отдельное железо L3 коммутаторы, к слову самые дешёвые из существующих с функцианалом MPLS/ospf/bgp/sfp+ и т.д. Те кто хотят построить сеть по дишману, при этом технологично и современно - микротик Ваш выбор. Покупайте железо под те нужды, под которые оно предназначается. К слову в режиме бордера с 2 fv, 6-ю IX, и локальным пирингом 1009 c 1 sfp+ тащит 2,5/2,5 гбита в лёт, при этом грузится не более 20%, а 1016 стеклянный - ващпе агонь. А что бы совсем проблемы не было arp timeout на 4 часа))))) Серия CCR - ЭТО МЛИН РОУТЕРЫ. У свичей расширенное меню настройки коммутации, на ccr это меню сильно кастрированно!