Пропадают пинги до шлюза провайдера mikrotik

Обновлено: 07.07.2024

Есть Mikrotik RB3011UIAS-RM, прошивка 6.47.10 stable, 2 WAN от двух разных провайдеров, адрес микрота 192.168.1.1, бридж 192.168.1.1/23. Во всех кабинетах стоит неуправляемый коммутатор, в который приходит кабель канал передачи данных (КПД) от провайдера. В эти неуправляемые коммутаторы в кабинетах подключены точки cAP ac и через CAPSMAN они работают в бесшовной сети. Микрот по DHCP раздает адреса всем клиентам.
Порты микрота:
eth1 - WAN от провайдера №1
eht2 - WAN от провайдера №2
eth5 - канал передачи данных(КПД) к провайдеру №1.
eth9 - напрямую подключенный компьютер 192.168.0.30

комп 192.168.0.30 (подключен напрямую в микрот eht9) пингует и шлюз 192.168.1.1, и принтер 192.168.1.230 и точку 192.168.0.253 всегда
ноут 192.168.1.101 (подключен по wifi к точке, которая подключена к коммутатору, который через КПД подключен к роутеру) пингует и шлюз 192.168.1.1, и принтер 192.168.1.230 и точку 192.168.0.253 всегда

комп 192.168.0.40 (подключен к коммутатору, который через КПД подключен к роутеру) перестает пинговать шлюз 192.168.1.1, но при этом пингует принтер 192.168.1.220 и точку 192.168.0.252, которые находятся в другом кабинете(этот кабинет тоже подключен через КПД)
ноут 192.168.1.100 (подключен к коммутатору, который через КПД подключен к роутеру) перестает пинговать шлюз 192.168.1.1, но при этом пингует принтер 192.168.1.220 и точку 192.168.0.252, которые находятся в другом кабинете(этот кабинет тоже подключен через КПД)

После 19-20 вечера(основная часть сотрудников БЦ уходит) пинг сам по себе появляется по всех кабинетах без каких-либо перезагрузок микротика или неуправляемых коммутаторов.

Провайдер приезжал тестировал, охренел с этой проблемы и сказал, что дело в микротике или в какой-то петле. Сказал, что их КПД чистый L2, и с ним никаких проблем нет. При этом провайдер посмотрел настройки микротика и сказал, что все вроде бы ОК.

Сегодня мы по очереди посреди дня выключали/включали на 5 мин коммутаторы во всех кабинетах(пытаясь найти петлю или взбесившееся устройство) и пинговали шлюз с другого кабинета - пинга так и не было.

Понятно, что сеть на неуправляемых коммутаторах плоха, но тут такие особенности БЦ, что они не дают прокладывать свою СКС, а заставляют пользоваться текущей. Учитывая все вышесказанное, какие могут быть варианты решения проблемы? Петли вроде как нет, в логах микрота никаких ошибок, провайдер говорит с их КПД все в порядке. Посоветуйте пожалуйста куда копать.

Что бы кто не говорил но оборудование Mikrotik так же выходит из строя как и обычный D-link. У него могут поехать мозги, сгореть порты да и в принципе все что угодно может с ним случиться. Ведь это электроника и она не совершенна. Например, расскажу про недавний случай, на оборудование Mikrotik происходит потеря пакетов. Поделюсь свои опытом по диагностированию и решению этой проблемы.

И так как же бороться с небольшой потерей пакетов на роутере Mikrotik RB2011UiAS-2HnD.

Предисловие и симптомы

Обратилась ко мне одна фирма с проблемой. В одном из офисов происходить прерывание связи на 1 сек при разговоре по IP телефонии. Происходит все это в разное время.

Первое обследование инфраструктуры выявило потерю пакетов при пинге любого ресурса в интернете. Например, те же 8.8.8.8. Внутри сети потерь ни каких не было.

Как видите потери не большие примерно от 3 до 10 %. На пользование интернетом это вообще ни как не отражается. А вот IP телефония к потерям очень чувствительна.

В качестве шлюза стоял Mikrotik RB2011UiAS-2HnD.

К нему был подключен кабель провайдера (Подключение по DHCP.) и три коммутатора. В сети было около 50 устройств, компьютере, сетевые принтеры, IP телефоны, видеокамеры. В общем стандартный набор среднего офиса. Это был центральный узел организации к нему, подключалось много других офисов. Замена его была самым последним вариантом.

Диагностика проблемы с потерей пакетов своими силами

Так как опыта у меня достаточно много, практически 10 лет. Полагаясь на него я начал диагностировать и пробовать решать проблему. Вот что было мною сделано.

1 Переобжат кабель провайдера. Не помогло.

2 Проверка линии провайдера. Не помогло.

3 Обновление Mikrotik и перезагрузка. Не помогло.

4 Проверка всех правил firewall, полное отключение. Не помогло.

5 Отключение всей сети от Mikrotik. Не помогло.

6 Проверка нагрузки на Mikrotik.

7 Переключение кабеля провайдера в другой порт откладывалось так выяснилось что при пинге до основного шлюза оператора потерь нет.

8 Замена Микротика откладывалась так же по этой причине.

9 При подключении кабеля провайдера напрямую потерь не было.

10 В логах ни каких ошибок не было.

На этом мои идеи иссякли.

Помощь Интернета

Дальше оставалось только гуглить. Информации на эту тему в интернете не много. Все способы которые я нашел, я конечноже проверил.

1 Были отключены все ограничения на полосу пропускания.

2 Отключение Allow Remote Requests в настройках DNS.

3 Отключение всех подключений к Mikrotik.

4 Отключение лишних пунктов в настройках IP Settings. Об этом даже есть ролик на ютубе.

Это были все белее менее вминаемые советы из интернета. Дошло даже до того что кто-то писал что нужно в разрез с провайдером поставить обычный свитч. Якобы у него подобным способ решилась проблема с потерей пакетов на Микротике. Проверено не работает)

В чем была проблема

В настройках DHCP Client заметил статус подключения error. Он периодически менялся, поиск ошибка, поиск ошибка. На скриншоте статус уже нормальный. Просто чтобы вы знали где его смотреть.

Решение проблемы с потерей пакетов Mikrotik

В общем оставалось два вариант, это подключение провайдера в другой порт и замена самого Mikrotik.

Объясню почему сразу не переключил кабель провайдера в другой порт. Я уже говорил выше, что пинг до шлюза самого провайдера был отличный без потери пакетов. Из опыта и здравого смысла можно сделать вывод что раз до шлюза потерь нет значит и с портом все нормально и с Mikrotik.

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

И вот случилось чудо. Потери прекратились!

В итоге потеря 3 -10 % пакетов решилась сменой порта подключения провайдера!

Так как я потратил на решение проблемы с потерей пакетов на Mikrotik RB2011UiAS-2HnD достаточно много времени. Решил написать эту статью и поделиться с вами своим опытом может кому пригодиться!

Добрый день форумчане, сложилась такая ситуация, что Микротик пингует все кроме провайдерского dns (их 4 штуки) Где я выполнил не правильную настройку - в фаерволе только форвард локалки, в нате - только маскарад в настройках днс 77.88.8.8 и один из провайдерских. Провайдер отдает PPPoE. С динамическим внешним адресом. Интернет бегает но тут еще одна проблема download в пределах тарифа , а вот upload - 0.01-1 мбит . Я в микротиках человека новый. И интернет уже рыл. RouteOs 6.34.4. UPD: с самого микротика dns пингуется (все 4)

Проверь настройку портов - настроен ли порт на PPPoe

И снабди ещё деталями

Конфиг в студию!

Асинхронный аплоад норма в этом мире. А про пинг - не понял. Микротик его пингует или нет? Провайдер точно icmp не дропает нигде?

Микротик пингует провйдерские: локалки и внешние адреса. Все что за микротиком не видит провйдерскую локалки и внешние адреса. Допустим с микротика я буду пинговатт lds.ua, а с локалки пинг не идёт туда

Там показывать не чего настраивал все по первым мануала в Гугле. Как буду за ним, скину то нечего, что есть

Привязка по маку есть. Мак я сменил. Пппое подключается и выдает десяток маршрутов которые доступны через интерфейс pppoe-out1, и там есть все маршруты и днс внутренние и внешние и локалка

Пока на словах. Бридж - eth2-4+wlan1; dhcp - bridge . Dns - добавил два , один 77.88.8.8 , второй 10.0.0.2 - провайдера . Ну и настроен pppoe client . Все. В днс ещё пишет по мимо этих двух 4 динамических.

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

Сделал для теста вот так: провайдер - тп-линк(скорость 40/20) - микротик (скорость 20/10) на микротике вообще нет настроек кроме бриджа, и маскарада и wifi настроен по дефолту. Все. Но заметил одну магическую штуку, что если подключить провайдер к микротику напрямую, то скорость порта не 100(как через тп-линк, а 10. Если убераю автоматическое определение скорости порта, а ставлю 100, то тогда отдача падает до 0.01 а загрузка выше 20 не поднимается. Как то давно читал , что кто-то гоаорил о том, что микротик начинает нормально работать после 3 резетов. 2 уже было .

Как то давно читал , что кто-то гоаорил о том, что микротик начинает нормально работать после 3 резетов. 2 уже было .

А если в бубен постучать, то все заработает само-собой. Что за бред вы пишите?

Хотите решить вопрос - скиньте сюда конфигурацию, гадать на кофейной гуще никто не будет.

Микротик не отвечает на пинги через WAN, mangle настроен, интернет есть. Что может быть не так?

Если вы ищете руководство по настройке dual-wan failover на микротике, то среди задач вы будете решать, как сделать, чтобы при пинге через ISP1 микротик направлял бы ответ через шлюз GW1, а при пинге через ISP2 - соответственно, через GW2.

Штука в том, что даже если все правильно настроено, и NAT работает, и локальные клиенты в сеть ходят, и firewall вроде разрешает пинг снаружи, а снаружи к микротику не обратиться. Не пингуется и все тут.

Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Вы наверняка видели что-то вроде:

/ip firewall mangle
add chain=input action=mark-connection new-connection-mark=ISP1->Input passthrough=no dst-address=IP1 in-interface=ether1
add chain=output action=mark-routing new-routing-mark=ISP1 passthrough=no connection-mark=ISP1->Input
add chain=input action=mark-connection new-connection-mark=ISP2->Input passthrough=no dst-address=IP2 in-interface=ether2
add chain=output action=mark-routing new-routing-mark=ISP2 passthrough=no connection-mark=ISP2->Input

Т.е.:
1) если пришел пакет со стороны провайдера ISP1 (через интерфейс ether1) с конечным адресом нашего микротика IP1 (т.е. в input), то пометить это соединение меткой "ISP1->Input".
2) исходящий трафик, связанный с установленным ранее соединеним, помеченным меткой "ISP1->Input", маршрутизировать по правилам таблицы ISP1.

Аналогично для входящих пакетов со стороны провайдера ISP2.

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

Но у вас могут быть только такие дефолтные машруты (до 0.0.0.0/0):

/ip route
add distance=1 gateway=GW1 routing-mark=ISP1
add distance=1 gateway=GW2 routing-mark=ISP2

и ни одного маршрута по-умолчанию без указания routing-mark. Т.е. основная таблица маршрутизации пустая.

При пинге IP1 снаружи через ISP1 (input) из примера выше входящий пакет будет принят, промаркируется соединение (new-connection-mark=ISP1->Input). А вот ответ (output) никуда не уйдет, т.к. ответный пакет не попадет в output. Вообще. И промаркирован он не будет. И микротик не отправит его никуда.

Решить проблему можно по-разному.

1. prerouting вместо output

2. добавить маршруты по-умолчанию без указания таблиц маршрутизации

Например, как-то так:

/ip route
add distance=1 gateway=GW1 distance=10
add distance=1 gateway=GW2 distance=10

Или даже просто один из них:

/ip route add distance=1 gateway=GW1 distance=10

Не важно, будет этот маршрут доступен или нет, осноная таблица маршрутизации не будет пустой и микротик начнет искать замену этому маршруту. А если в основной таблице пусто - то и микротик делать ничего не будет и дело не дойдет до момента маркировки пакета в mangle -> output.

Сюда вошли наиболее типичные проблемы микротик и их решения.

Теперь они собраны в одном месте, а не разбросаны по крупицам по всему интернету.

6.1. Как ходит трафик в Микротик?

Представьте компьютер с двумя сетевыми картами. Будем называть его ШЛЮЗ.

В одну карту входит интернет. Со второй выходит к свитчу.

А к свитчу подключены другие компы.

За этими компьютерами люди в интернете выходят.

Это левая диаграмма. Как раз наш случай с Микротик.

А если на самом шлюзе запускаются браузер, почта и пр.

Это левая и правая диаграмма, только без центрального блока FORWARD.

В Микротике правая практически никогда не задействована.

Так что про INPUT-OUTPUT забудьте.

Только для блокировки входящих пакетов.

Никаких локальных адресов в пакете нет, только внешний адрес Микротика!

Происходит подмена (из таблицы NAT) для входящих пакетов внешнего IP на локальный.

или DstNat (это для тех, кто пытается достучаться до локальных IP-адресов из интернета)

3. Теперь срабатывают правила в цепочках Mangle Forward и Filter Forward.

Тут уже можно фильтровать клиентов вашей сети.

4.Далее снова срабатывает NAT.

Здесь создаются записи в таблице NAT для исходящих пакетов. Т.е. срабатывает SRC-NAT.

По этим записям будет происходить обратная замена IP, когда придут ответные пакеты.

И для исходящих пакетов происходит подмена локального IP 192.168.0.2 на IP Микротика 80.80.80.1.

Никаких локальных адресов в пакете нет, только внешний адрес Микротика!

Далее все это направляется в шейпер. Queue Tree и Simple Queue.

Для Транзитного трафика:
сеть -> mangle PREROUTING -> nat PREROUTING -> mangle FORWARD -> filter FORWARD -> mangle POSTROUTING -> nat POSTROUTING -> сеть

6.2. Firewall Filter — блокируем и разрешаем.

Здесь создаются блокирующие и разрешающие правила.

Порядок записей имеет значение.

Проверка правил происходит сверху вниз.

Если пакет соответствует правилу, то дальнейшая проверка не происходит, если конечно не стоит галка PassTrugh

Есть 2 варианта.

Блокируется или входящие пакеты или исходящие.

Важно!

1. Никогда не пытайтесь одним правилом блокировать входящие и исходящие пакеты одновременно.

Да и Роутер разгрузится от лишнего входящего трафика.

Важно! Src.Address и Dst.Address в правилах меняются местами. В зависимости от направления движения пакета.

3. В правилах всегда указывайте Out. Interface или In. Interface.

Это очень важно!

То же самое (п. 1 и 2) касается и Mangle.

6.3. NAT. Проброс портов.

6.4. Маркировщик Mangle. Следим и помечаем трафик.

Это очень мощное средство. Позволяет маркировать пакеты по любым правилам. Подчиняется тем же правилам, что описаны в разделе 6.2. FireWall Filter. Но Мангле ничего не запрещает и не разрешает. Он просто помечает трафик: соединения, пакеты, маршруты и пр. Умеет также добавлять в AddressList, Менять TTL пакетов, приоритет, порядок цепочек и пр. пр. Это для дальнейшей обработки в фаерволе или шейпере.

6.5. Address List. Для чего он?

Это в основном для того, чтоб не указывать кучу однотипных правил для разных IP, а кинуть эти IP в один Address List. И затем создать только одно правило на этот Address List.

Чрезвычайно удобная штука!

6.6. Нарезаем скорость. Simple Queues.

Важно! Проверка правил шейпера происходит сверху вниз. Если какое-то правило шейпа сработало, то дальнейшая проверка уже не производится!

Добавляем IP или список IP, для которых в сумме можно выставить максимальную скорость Max Limit.

Отдельно входящую и исходящую скорость.

А также потребленный входящий и исходящий трафик. (Rx Avg. Rate и Tx Avg. Rate )

Начиная с момента последней перезагрузки роутера.

Можно скорости писать в виде 500K, 2M, а также можно указать скорости Burst Limit (с Burst TreshHold, Burst Time)

Это взрывная кратковременная скорость.

Очень эффективно при низко скоростных тарифах и если Вас качальщики задрали.

Веб сайты открываются тогда моментом на Burst скорости, а закачки идут на обычной скорости.

Если у Вас Dual Access, то можно для каждого клиента создать еще одну дополнительную запись с высокой скоростью на локальные ресурсы.

Эту запись нужно поставить выше основной записи клиента.

Если Вы скорость на локальные ресурсы не хотите подрезать вообще, то

и поместить ее на самый верх.

Важно! Очень советую в самый конец добавлять правило END.

На этом правиле будет учитываться, подрезаться или блокироваться весь неучтенный трафик.

Ну например Вы по невнимательности забыли кого-то добавить в шейпер.

И человек получит всю доступную скорость без любых огранечиний! Тем самым может положить канал!

Правило END для учета и подрезки неучтенного траффика:

add interface=all max-limit=100k/100k name=END target-addresses=192.168.0.0/16

По функциональности он гораздо шире. Этот шейпер срабатывает раньше Simple Queue.

Эффективен особенно при методе PCQ.

И большом количестве клиентов 100 и более.

В нем входящая и исходящая скорости нарезаются отдельными правилами.

Он работает только в связке с Мангле.

Это тарифные планы.

2. Далее в IP-Firewall-Mangle маркируем Connection-ы.

Эти два правила будут будут нарезать трафик всем клиентам.

Достаточно адрес IP клиента добавить в нужный Adrress List.

Все остальное аналогично.

А как же смотреть, кто сколько скачал и на какой скорости и кто качает?

Эти записи ставим ниже записей mark-connection и mark-packet.

6.8. Включаем Графики.

Графики трафика доступны для всех интерфейсов, и Simple Queue. А также доступны графики загрузки процессора, памяти, flash-памяти. За сутки, за неделю, за месяц, за год.

Просто добавьте нужные позиции.

Посмотреть графики можно на Веб-странице Микротика.

При перезагрузке графики сохраняются.

При прошивки графики сбрасываются.

6.9. IPTV настройка.

Скачиваем версию пакетов под ваш Микротик

Важно! Версия пакета должна совпадать с версией вашей Router OS!

Далее идем в System-Packages. Там должен быть multicast пакет.

6.10. Резервирование 2 и более каналов.

По умолчанию пакеты идут через WAN1.

6.11. Балансировка 2+ каналов.

Балансировка через маршруты. Соединения вперемешку будут идти через WAN1 или WAN2

Метод хорошо работает при каналах приблизительно равных по скорости.

Разница по скорости каналов не должна отличаться более чем в 2 раза.

Можно добавить еще маршрут без маркировки на всякий пожарный:

Важно! При каналах сильно отличающихся по скорости он мало эффективен.

В таком случае советую использовать резервирование каналов по п. 6.10.

Слабый канал погоды все-равно не сделает. А скоростному мешать будет.

6.12. Запрет определенных сайтов по имени.

Открываем New Terminal. И вставляем наше правило. Не забудьте поднять его наверх.

Можете также вручную кнопкой [+] создать это правило.

Тем самым Вы блокируете только исходящие запросы еще на взлете.

Роутеру уже на нужно фильтровать входящие пакеты от этого сайта,

А исходящий трафик обычно в 10-20 раз меньше входящего.

Да и фильтруются только исходящие TCP запросы.

Что есть очень хорошо.

Если нужно блокировать доступ к сайту для всех компов, убираем эту строчку src-address.

6.13. Определяем у кого стоят роутеры по TTL.

Все IP адреса, которы сидят за роутерами, попадут в Address-List Router

И наоборот, можно спрятать вашу сеть от фильтра TTL провайдера.

Это правило поднимите на самый верх.

6.14.Блокируем порты спамеров.

1. Блокируем порты спамеров и зараженных троянами-вирусами компов.

2. Добавляем в address-list=spammer наших спамеров на 30 дней :

Вы же не хотите, что бы Ваш провайдер Вам закрывал порты? Или хотите?

6.15. Настройка Static DNS.

Static DNS
нужен чтобы к любому компу в сети обращаться не по IP адресу, а по придуманному имени. Что очень удобно.

6.16.Кешируем с помощью Web-Proxy.

Кеширование используется для:

1. Ускорения интернет. Особенно Эффективно при медленном интернете.

Часто запрашиваемые файлы хранятся на флеш-памяти или винте.

2. Для экономии траффика. Хорошо при платном траффике.

Весь трафик проходит через прокси микротика.

На прокси ставиться порт 8080.

И затем включается прозрачный прокси.

6.17. Редирект на страницу-напоминалку.

К примеру у Вас есть комп в сети 192.168.0.10. Там находится Веб-сервер и страница-напоминалка-пополнялка-личный кабинет. Она доступна по адресу 192.168.0.10

Это правило кинуть выше правила srcnat!

Все. редирект работает.

Эти правила кинуть вниз.

Это для полной блокировки любой активности (а не только ВЕБ-серфиннг) юзеров, которые не в ALLOW.

Один клик и готово.

4. На вебсервере в корне страницы-напоминалки добавляем файл .htaccess с редиректом :

RewriteEngine on
RewriteCond % !-d
RewriteCond % !-f
RewriteRule .* /index.html [L,QSA,NC,R=302]

А в 404.php сделать include вашей страницы напоминалки.

Или просто скопировать ее содержимое.

Вот так все просто.

6.18. Шейпим торренты.

Данный метод режет все торренты. И шифрованные в том числе. И он не ресурсоёмкий для Микротика.

Маркируем входящие торрент-пакеты по размерам, портам и протоколам:

В Simple Queue можно каждому указать скорость на торрент в отдельности.

Т.е. для каждого IP создать дополнительную запись.

Эта запись должна быть выше основной записи IP клиента.

Или уже решайте на свое усмотрение, что с этими маркированными пакетами делать.

Читайте также: