Скорее всего софтовая. И все-таки.
Сделайте сброс конфига и настройте минимум!!!
Только WAN, DHCP, и NAT. ну и port mapping.
Я бы еще у провайдера MAC перерегистрировал, чтобы никакого клонирования.
Никаких правил фаерволла, никакого снифера и так далее.
Уверен, все будет работать.
У меня есть места, где микротик держит по 25000 и больше входящих соединений. И хоть бы хны. Но у меня только минимум, никаких лишних правил. Мне важнее стабильность.
Пятиминутный затык на внешнем интерфейсе - РЕШЕНО
-
- Сообщения: 11
- Зарегистрирован: 28 июл 2014, 12:56
gmx писал(а):Скорее всего софтовая. И все-таки.
Сделайте сброс конфига и настройте минимум!!!
Только WAN, DHCP, и NAT. ну и port mapping.
Я бы еще у провайдера MAC перерегистрировал, чтобы никакого клонирования.
Никаких правил фаерволла, никакого снифера и так далее.
Уверен, все будет работать.
У меня есть места, где микротик держит по 25000 и больше входящих соединений. И хоть бы хны. Но у меня только минимум, никаких лишних правил. Мне важнее стабильность.
сбросил на заводские настройки, запустил скрипт настроек по умолчанию с маскарадингом, таже ситуация. отключил все блокирующие правила на сколько понимаю для цепочки форвард политика по умолчанию принимать соединения, таже ситуация.
сдается мне что верно первое же предположение в теме блокировка провайдером. скоро раздобуду тик 750, испытаю на нем, что должно с высокой долей вероятности подтвердить либо опровергнуть.
ПС есть еще третий вариант лыжи не едут, это первый мой микротик
-
- Модератор
- Сообщения: 3416
- Зарегистрирован: 01 окт 2012, 14:48
Опять какой-то скрипт?
Все вручную после сброса надо настраивать. И пока никаких правил фаерволла вообще быть не должно. Вообще ничего. В идеале: бридж, WAN и бесконечный пинг в терминале.
Все вручную после сброса надо настраивать. И пока никаких правил фаерволла вообще быть не должно. Вообще ничего. В идеале: бридж, WAN и бесконечный пинг в терминале.
-
- Сообщения: 11
- Зарегистрирован: 28 июл 2014, 12:56
по порядку:
снова вернулся к старым настройкам, потому как если сброс настроек не попмогает незачем тратить время, но:
заработало!
я представлял себе настройку нат таким образом:
то есть пройти за нат пакету будет позволено только в двух случаях, либо если пакет связан с уже установленным соединением, либо новое соединение может быть создано по известному порту и при соответствующем правиле днат, но практика странным образом разошлась с теорией, потребовалось правило
и
осталось невыясненным верно ли мое понимание нат, соответствовал ли конфиг теории, будут ли корректно работать приложения при "моих" настройках нат и в чем все же причина 5 минутного затыка, связано ли это с тем как отслеживаются состояния пакета в микротике
прошу меня поправить если я не прав.
благодарю за Ваше желание помочь и практические советы. если столкнетесь с подобным затыком или будет интерес понять точную причину столь странного поведения, пишите.
ПС при новом конфиге от чего то много пакетов дропается на цепочке input, по количеству IP адресов понятно что это "хвосты" торрентов, но не понятно что то им не дает попасть в forward
ПС2 количество одновременных соединений выросло с 300 до 800-900, затыка нет
- 1 переназначили мак на оборудовании провайдера - не помогло
2 сбросил на заводские, выполнил минимум настроек (адрес ван, дхцп, бридж) добавил в нат снат без единого правила на фаеволе - не помогло
снова вернулся к старым настройкам, потому как если сброс настроек не попмогает незачем тратить время, но:
- а) убрал статическую арп запись для шлюза провайдера
б) к политике по умолчанию сбрасывать все пакеты для всех цепочек добавил правила дропать инвалидов и выставил их выше остальных правил
в) разрешил в цепочке форвард исходящие и входящие на внешний интерфейс без условия что источником пакета является локальная сеть!
г) поменял маскарад на снат и прочие мелочи
заработало!
я представлял себе настройку нат таким образом:
- 1) включаем ip firewall nat, пакеты с внешнего интерфейса отправляются в нат таблицу,
2) все исходящие из локали в цепочке форвард принимаем фаером ip firewall filter,
3) входящие в локаль пакеты будут пропускаться фаером только по состоянию established, related
для иницирования входящих извне создаются правила днат и соответствующие правило фаера
то есть пройти за нат пакету будет позволено только в двух случаях, либо если пакет связан с уже установленным соединением, либо новое соединение может быть создано по известному порту и при соответствующем правиле днат, но практика странным образом разошлась с теорией, потребовалось правило
и
осталось невыясненным верно ли мое понимание нат, соответствовал ли конфиг теории, будут ли корректно работать приложения при "моих" настройках нат и в чем все же причина 5 минутного затыка, связано ли это с тем как отслеживаются состояния пакета в микротике
прошу меня поправить если я не прав.
благодарю за Ваше желание помочь и практические советы. если столкнетесь с подобным затыком или будет интерес понять точную причину столь странного поведения, пишите.
ПС при новом конфиге от чего то много пакетов дропается на цепочке input, по количеству IP адресов понятно что это "хвосты" торрентов, но не понятно что то им не дает попасть в forward
ПС2 количество одновременных соединений выросло с 300 до 800-900, затыка нет
-
- Модератор
- Сообщения: 3416
- Зарегистрирован: 01 окт 2012, 14:48
Да проще все можно
вот мое правило NAT
chain=srcnat action=masquerade src-address=192.168.77.0/24
Все! Если у вас DHCP клиент, то нужно еще указать физический интерфейс, на котором он работает.
И все!!!
Подозреваю, что с вашими настройками провайдеру на оборудование уходило больше одного MAC адреса, вот он блочил интерфейс.
вот мое правило NAT
chain=srcnat action=masquerade src-address=192.168.77.0/24
Все! Если у вас DHCP клиент, то нужно еще указать физический интерфейс, на котором он работает.
И все!!!
Подозреваю, что с вашими настройками провайдеру на оборудование уходило больше одного MAC адреса, вот он блочил интерфейс.
-
- Сообщения: 11
- Зарегистрирован: 28 июл 2014, 12:56
да вот тоже посмотрел на свой конфиг на свежую голову и не пойму чего же я такого изменил и не нашел! 
единственное что сопоставимо на мой взгляд с интервалом в пять минут - это время жизни арп записи, но пока проблема не наблюдается. если мне нечем будет заняться, я начну менять маки обратно
проверено!
при подмене мака внешнего интерфейса на мак пк и запуске торрентов происходит тот самый затык.
проблема локализована!
ПС значит тик в отличии от домашнего роутера не умеет клонировать адрес без вреда для самого себя. возможно надо уметь разграничить фаером подсети, чтобы не пересекались маки
ПС2 одно из самых первых предположений было что 5 минут живет арп, добавил шлюз в статику и успокоился, и подумал что тик для такой фичи как клонирование адреса сам придумает решение. подмена мака на сетевой карте пк, от чего то не давала результата

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

проверено!
при подмене мака внешнего интерфейса на мак пк и запуске торрентов происходит тот самый затык.
проблема локализована!
ПС значит тик в отличии от домашнего роутера не умеет клонировать адрес без вреда для самого себя. возможно надо уметь разграничить фаером подсети, чтобы не пересекались маки
ПС2 одно из самых первых предположений было что 5 минут живет арп, добавил шлюз в статику и успокоился, и подумал что тик для такой фичи как клонирование адреса сам придумает решение. подмена мака на сетевой карте пк, от чего то не давала результата
-
- Сообщения: 11
- Зарегистрирован: 28 июл 2014, 12:56
gmx писал(а):Да проще все можно
вот мое правило NAT
chain=srcnat action=masquerade src-address=192.168.77.0/24
Все! Если у вас DHCP клиент, то нужно еще указать физический интерфейс, на котором он работает.
И все!!!
Подозреваю, что с вашими настройками провайдеру на оборудование уходило больше одного MAC адреса, вот он блочил интерфейс.
перед тем как постить тему читал ветку про блокировку провайдером если на внешний интерфейс уходит более одного мака, не мой случай. в моем случае вероятно происходил сбой в "внутри" маршрутизатора. надо смоделировать чтобы понять
-
- Модератор
- Сообщения: 3416
- Зарегистрирован: 01 окт 2012, 14:48
Попробуйте на бридже включить протокол STP/RSTP.
Возможно тогда микротик запишет в лог проблему.
Возможно тогда микротик запишет в лог проблему.
-
- Сообщения: 11
- Зарегистрирован: 28 июл 2014, 12:56
gmx писал(а):Попробуйте на бридже включить протокол STP/RSTP.
Возможно тогда микротик запишет в лог проблему.
возможно, попробую. но я добавлял в логирование все события маршрутизации, думаю rstp должен был сказать о коллизии, о перестроении маршрута или интерфейс должен был бы перейти в down, чего замечено не было. пока для меня микротик как черный ящик.
допустим деятельность rstp не отражалась в логах, протокол не вырубал внешний интерфейс, вполне, пакеты для внешнего интерфейса шли в локаль, но от чего же тогда nethop определялся без пробюлем? nexthop может не иметь мака?
ПС в технической поддержке "верят" в то что проблема возможно была поправлена в новой прошивке, хотя и сильно смахивает на стандартный ответ не разработчика
"you have been using version of 6.17. I believe that this issue might be
fixed in one of our release candidate versions. At least there is fix for arp list
which is affected by changing mac address"
ПС показалось отключить рстп, рстп был включен
-
- Модератор
- Сообщения: 3416
- Зарегистрирован: 01 окт 2012, 14:48
Я не знаю, настолько глубоко я не вникаю в процессы. В моем понятии все просто - я видел просто пароноидальное поведение протоколов RSTP/STP на коммутаторах. И у себя и у других провайдеров. Причем отказ в обслуживании может произойти ну просто совсем по непонятным причинам. На любой чих, переткнул случайно кабель, несколько раз быстро (типа плохой контакт) - все отказ в обслуживании. Как там у провайдера настроено, мы можем только гадать.
Именно поэтому я в самом начале рекомендовал привести MAC в сети к уникальному состоянию. Это просто на опыте основано и не только с микротиками. И на работе тоже у меня четкий принцип, никаких повторяющихся MAC, даже если сети не пересекаются. Через год-два, случайно переткнут железку в другую стойку и потом проблему можно искать неделю. Были случаи, производители экономили на MAC - это просто задница.
Именно поэтому я в самом начале рекомендовал привести MAC в сети к уникальному состоянию. Это просто на опыте основано и не только с микротиками. И на работе тоже у меня четкий принцип, никаких повторяющихся MAC, даже если сети не пересекаются. Через год-два, случайно переткнут железку в другую стойку и потом проблему можно искать неделю. Были случаи, производители экономили на MAC - это просто задница.