А непосредственно к дсл-доутерам только ваш микротик подключен или еще есть смежные девайсы?

он будет работать от 4 дсл , а дальше уже внутрення сеть.

очень помог, с чек гейтвеем не столь сложно. а вот балансировку сделать, когда 2 из 4 слягут, будет сложнее. или это мне так кажется

ecmp load balancing смотри там можно указывать веса и тд

А что с вай-фай как получилось ?

Почему не попробовать это ?

Или у Ромы спросить

Как можно нарастить витую пару? Дома в серверной до патч-панели у 10-12 кабелей не хватает 15-20 см.

Паять 12 кабелей замучаюсь

скотчлоки

или обжать и проходными адаптерами RJ-45

громоздко, но паять не надо

Думал над этим, но действительно 10 адаптеров занимают много места. Спасибо

Коллеги по микротикам! Ищется айтишник в Сочи. Задача - взять на обслуживание системы отеля - скс с wifi и ip-видеонаблюдением. Роутер микротик, точки ubiquity, видеокамеры и регистратор bsp security. В личку.

Репостните по схожим чатам, если есть такие

репостнул двоим коллегам в Сочи.

Небольшая заморочка возникает только если провайдер раздает адрес по dhcp. Там проще забрать статику, договорившись с провайдером.

У меня с динамикой все прекрасно работает

репостнул двоим коллегам в Сочи.

Спасибо

У меня с динамикой все прекрасно работает

Как указываете ip для check-gateway в динамике? Скриптом костылите?

У меня 2 прова

И оба с динамикой? Dhcp?

Парни 64 bit as так и не поддерживает микрот? В routing filters раньше к примеру комьюнити не льзя было докинуть для 6 значных AS

1й с динамикой пппое, 2й лте

1й с динамикой пппое, 2й лте

И как вы отслеживаете состояние gateway на динамике? Откуда берется ip для check-gateway?

так check-gateway можно же и не сам ip прова проверять... можно любой брать

главное чтоб через то подключение шло

И как вы отслеживаете состояние gateway на динамике? Откуда берется ip для check-gateway?

http://www.technotrade.com.ua/Articles/mikrotik_2isp_setup_2015-06-19.php по этой инструкции делал

так check-gateway можно же и не сам ip прова проверять... можно любой брать

Вы путаете с netwatch. Для check-gateway используется ip-адрес указанный в свойствах маршрута. Когда маршрут создается динамически (dhcp default route), gateway ip может прилететь любой из подсети

Парни 64 bit as так и не поддерживает микрот? В routing filters раньше к примеру комьюнити не льзя было докинуть для 6 значных AS

Что bgp + mikrotik ни у кого нету?

Есть

У кого-то обязательно есть

Нету, похоже ни у кого тут на микротике 64bit AS. Вообще bgp full view редко кто на микротике поднимает

Вы путаете с netwatch. Для check-gateway используется ip-адрес указанный в свойствах маршрута. Когда маршрут создается динамически (dhcp default route), gateway ip может прилететь любой из подсети

я нет пару минутак покажу как

Ок. Интересно. Nikolai: Если только запретить получать default-route по dhcp

Господа, всем дратути. А помогите разобраться с OSPF. Маршрутизация настроена и работает хорошо, НО! После падения-поднятия тоннелей вылезает вот такая печаль

Если только запретить получать default-route по dhcp

но при этом на узлах дублей нет

везде ID прописаны верно, дублей нет

ecmp load balancing смотри там можно указывать веса и тд

знаком с ним. ок, по маршрутам будет балансировать на пару с фаерволом. там по дистанцу каналы равнозначны. как оно тогда переключится , при падении одного из 4?!

# Настроим сети провайдеров: /ip address add address=10.100.1.1/24 interface=ISP1 /ip address add address=10.200.1.1/24 interface=ISP2 # Настроим локальный интерфейс /ip address add address=10.1.1.1/24 interface=LAN # скроем за NAT все что выходит из локальной сети /ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat #Пометим каждое соединение пришедшее снаружи и адресованное нашему роутеру: /ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1 /ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2 #что бы отвечать через те же интерфейсы, откуда пришли запросы, поставим соответствующую роутинг-марку на каждое соединение. /ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP1 new-routing-mark=rout_ISP1 passthrough=no /ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP2 new-routing-mark=rout_ISP2 passthrough=no #добавим default gateway в каждую из промаркированных таблиц маршрутизации: /ip route add distance=1 gateway=10.100.1.254 routing-mark=rout_ISP1 check-gateway=ping /ip route add distance=1 gateway=10.200.1.254 routing-mark=rout_ISP2 check-gateway=ping #промаркируем весь траффик из локальной сети /ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=mixed #используем ECMP для балансировки траффика из локальной сети /ip route add dst-address=0.0.0.0/0 gateway=10.100.1.254,10.200.1.254 routing-mark=mixed

знаком с ним. ок, по маршрутам будет балансировать на пару с фаерволом. там по дистанцу каналы равнозначны. как оно тогда переключится , при падении одного из 4?!

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

знаком с ним. ок, по маршрутам будет балансировать на пару с фаерволом. там по дистанцу каналы равнозначны. как оно тогда переключится , при падении одного из 4?!

Для каждого из 4 шлюзов задаем check-gateway. При недоступности одного из 4 шлюзов указаных в ECMP маршруте, роутер сам перенаправит трафик через оставшинся доступные шлюзы.

Ок. Интересно. Nikolai: Если только запретить получать default-route по dhcp

https://habrahabr.ru/post/244385/

там

конфигурация: failover с более глубоким анализом канала

и ты чекаешь получается гугл

Проблема в том, что если роутер делает NAT и для каждого линка к каждому шлюзу используется отдельный внешний IP, соединения установленные через упавший шлюз будут пересоздаваться с новым SRC-IP

так при такой схеме можно интерфейс выбирать

а не ip

хотя сам не делал могу обманывать

надо на стенде попробовать я не помню уже чего на роутинге делали с этим но делали точно

и ты чекаешь получается гугл

Только, чтобы маршрут на гугл разрешался рекурсивно, надо для гугловского IP (тот же 8.8.8.8/32) явно задать маршрут через шлюз (IP) провайдера. А он заранее неизвестен. Для аплинка с dhcp такой финт не канает

Только, чтобы маршрут на гугл разрешался рекурсивно, надо для гугловского IP (тот же 8.8.8.8/32) явно задать маршрут через шлюз (IP) провайдера. А он заранее неизвестен. Для аплинка с dhcp такой финт не канает

шлюзом же может быть и интерфейс...

шлюзом же может быть и интерфейс...

Только для линков точка-точка. Для broadcast-линков, типа ethernet или wifi это может вызвать глюки и отвалы линка

да

К тому же, для check-gateway нужен IP

Ethernet- итнерфейс с проводом до коммутатора доступа может быть в состоянии UP, а далее связи нет

Ethernet- итнерфейс с проводом до коммутатора доступа может быть в состоянии UP, а далее связи нет

для этого и рекурсия используется с проверкой гугла или еще чего

роутинг до гугла упал все зависимые маршеруты тоже

Для рекурсии всегда нужен конкретный IP шлюза провайдера, через которого идти до гугла. Указание ethernet-интерфейса в качестве шлюза работает некорректно на сетях больше чем /32

Для рекурсии всегда нужен конкретный IP шлюза провайдера, через которого идти до гугла. Указание ethernet-интерфейса в качестве шлюза работает некорректно на сетях больше чем /32

да есть такое... на вики Advanced Routing Failover without Scripting пишут и для тотка точка не пашит иногда

получается скриптом брать шлюз и в роутинг

Просто представьте себе картину L2. Сеть доступа, например /25. В сети болтается активными около сотни хостов. И тут некий дурной клиент начинает через интерфейс слать пакеты для 8.8.8.8. Не на чей-то мак, а вообще, всем? Бродкастом?! кто ему ответит? Лотерея?

можно и днсы прова

тут же не суть гугл чекать

а кого то в сети прова как вариант днс

или dhcp сервер :)

получается скриптом брать шлюз и в роутинг

Вот, тема-то и была, как избежать скриптов. При DHCP, штатно - никак.

а шлюз по dhcp всегда разный? у билайна к примеру всегда один это сам длинк или алькатель куда провод идет

а кого то в сети прова как вариант днс

У прова как раз может внутренняя сеть работать, а линк к магистралам упасть. Для этого и чекают гугл или яндекс

Просто представьте себе картину L2. Сеть доступа, например /25. В сети болтается активными около сотни хостов. И тут некий дурной клиент начинает через интерфейс слать пакеты для 8.8.8.8. Не на чей-то мак, а вообще, всем? Бродкастом?! кто ему ответит? Лотерея?

ему гейтвей ответит

ему гейтвей ответит

С какого перепуга именно гейтвей?

С какого перепуга именно гейтвей?

дратути

ему гейтвей ответит если там арп прокси стоит

или как там его

А если в сети несколько гейтвеев? Или у кого-то из клиентов два прова и он может стать транзитом?

это ипв4... если хост не знает мак 8.8.8.8, он спросит у дефолтгейтвея

А если в сети несколько гейтвеев? Или у кого-то из клиентов два прова и он может стать транзитом?

с ипв6 путаете

в ипв4 в подсети только один дефолтгейт

Арп прокси ответит, если сочетание IP+MAC есть на одном из интерфейсов шлюза. Вряд ли шлюз провайдера знает MAC гугловского 8.8.8.8 не имея с ним L2 связи

у прова это выключено должно быть у нормального

чтоб он не отвечал

Арп прокси ответит, если сочетание IP+MAC есть на одном из интерфейсов шлюза. Вряд ли шлюз провайдера знает MAC гугловского 8.8.8.8 не имея с ним L2 связи

Смотря как настроешь, он может и отвечать вообще на любой запрос

у прова это выключено должно быть у нормального

Воот. Значит, шлюз прова и не ответит

Просто представьте себе картину L2. Сеть доступа, например /25. В сети болтается активными около сотни хостов. И тут некий дурной клиент начинает через интерфейс слать пакеты для 8.8.8.8. Не на чей-то мак, а вообще, всем? Бродкастом?! кто ему ответит? Лотерея?

Возможно в случае маски у клиентов /0, тогда вполне возможно сработает, но интернета, при таком решении не видать.

Именно. Не видать.

Именно. Не видать.

Поправил, спасибо.

Смотря как настроешь, он может и отвечать вообще на любой запрос

Ну это уже сильное извращение со стороны провайдера. Я такого пока не наблюдал. Хотя и не искал спецом.

Поправил, спасибо.

Да я не про грамматику. Я про смысл.

Просто представьте себе картину L2. Сеть доступа, например /25. В сети болтается активными около сотни хостов. И тут некий дурной клиент начинает через интерфейс слать пакеты для 8.8.8.8. Не на чей-то мак, а вообще, всем? Бродкастом?! кто ему ответит? Лотерея?

а почему оно бродкастом-то? дефолтгейт не прописан?

Ну это уже сильное извращение со стороны провайдера. Я такого пока не наблюдал. Хотя и не искал спецом.

Бывает такое делают если за гейтом абонента вай фай что бы арпами не дрочить точки

Короче. Резюме: при указании в качестве шлюза ethernet-интерфейса, инета запросто может не быть. Не обязана такая схема работать.

Короче. Резюме: при указании в качестве шлюза ethernet-интерфейса, инета запросто может не быть. Не обязана такая схема работать.

в микротике всмысле?

Да и не относится РУЧНОЕ создание маршрута со шлюзом-интеофейсом к теме безскриптового мониторинга линка с dhcp