Nikita
Nikita
Вообще можно в dhcp маршруты отправить, но эт не про микротик)
Дэн Миков PRM
Вообще можно в dhcp маршруты отправить, но эт не про микротик)
Он же вроде любую опцию может отправить, главное её закодить правильно
Sergio
Стоит на окне микротик и там же телефон, микротик направлен, а скорости разные!
Встречался с очень интересными окнам, с какими то добавлениями, которые через себя не пущали вифи и лте…
Но не суть, можно перейти в личку, и могу глянуть настройки вашего микрота на подоконнике
Бу...
Вообще можно в dhcp маршруты отправить, но эт не про микротик)
И про микротик тоже, 121/249 опции раздавали статику с микротика без проблем. Но считать муторно.
Nikita
Бу...
В л2тп?
А почему нет? https://forum.mikrotik.com/viewtopic.php?t=190494
Но надо тестить, потому что у нас был голый езернет на /22, а тут тоннель, броадкаст там не летает (для dhcp), потому прокатит это вариант или нет - под вопросом.
Nikita
Бу...
На 6 не работало, на 7 честно говоря не пробовал
Потому обычно и делают, СМАК для разворачивания подключения, на клиенте слушатель rip, а дальше уже по rip скармливать маршруты. Но это изначально костыльное решение, я про маршруты на клиенте
Petr
На клиенте ещё можно использовать замечательный add-vpnconnectionroute, вместо макаревичей
Ну и если речь про 7-ку, то проще всего кмк настроить ikev2 + radius + скрипт для LE сертификата
На 10 минут больше времени потратить, зато сразу нормально все работает без лишних костылей
Евгений
Коллеги, добрый день, в последний месяц испытываю проблемы с тоннелем Микротик-Керио l2tp\ipsec, 2-3 раза в день подключение разрывается, иногда при перезапуске identity сразу переподключается, а иногда по минут 20 не может подключиться, перед тем как разорваться статут подключения меняется с established на expired. Подключение пытается установиться выходит то message 1 sent, то 2. Даже не знеаю куда копать, ранее всё работало без проблем
Иван
Добрый день, коллеги. У меня есть такая задача, необходимо сделать стенд офисной корпоративной сети, для проверки работы gre туннелей между офисами, для выявления отказоустойчивости и приоритетов трафика туннелей. Шлюзы развернуты на микротиках 6 os. Подскажите в какой среде это лучше всего развернуть, используя имеющуюся конфигурацию.
Андрей
Не обращался, думаете к ним вопрос?
В целом - не совсем к ним, скорее к РКН, но начинать стоит с чтения нормативки, рекомендаций госорганов и обращения к оператору связи, с целью - включить в белый список свой впн-сервер.
Vadik
Innokentiy
вы жалуетесь или хвастаетесь?
Nemexis
Maxim
SoyuzNet
Nemexis
на данной модели только SFP+
Nemexis
Nemexis
да, это за 22 часа набралось
Nemexis
если поставлю другой CRS-326-24g-2S+ c тем же модулем, ошибок не будет. Вот и вопрос, может это проблемы конкретно даного CRS-326-24g-2S+ брак?
SoyuzNet
SoyuzNet
Попробуйте принудительно выставить скорость порта
Олег
drop - это не физические ошибки
Innokentiy
Innokentiy
как Олег заметил, это не про то, что нечто было отправлено в среду, но отправлено как-то неправильно (в ethernet не существует обратной связи, которая бы позволила про такое узнать)
Innokentiy
это про то, что нечто даже не было возможности попытаться отправить, потому что буферы на передачу были забиты полностью
Innokentiy
и его пришлось дропнуть
Innokentiy
заменой проводов, обкуриванием благовониями или принесением в жертву черного козла это не лечится. рецепта три
- либо отправлять поменьше/пореже и не допускать микроберстов
- либо поставить другую железку, у которой буферы толще
- либо признать, что 0.0001% потерянных в транзите не влияют ни на что (если это так)
Sasha
Innokentiy
не мог
Innokentiy
отправитель в ethernet ничего не знает о «получателе» или «получателях», даже о том, сколько их, не говоря уж о том, чтобы отслеживать состояние приема чего-либо на них
Nemexis
Заменил железку, на ту что без проблем
Nemexis
Эту поставлю в менее ответственное место
Nemexis
Спасибо всем
Innokentiy
да это не «проблема» же
Innokentiy
просто представьте: у вас на свитче есть три порта, к которым подключены компьютеры (А, В и С)
А и В одновременно отправляют кадры получателю С, свитч их одновременно же отправить не может, он выбирает некоторым образом один, который отправит сразу, и второй складывает в буфер на отправку потом
Innokentiy
пока он это делает, А и В присылают еще каждый по кадру, теперь уже оба они складываются в буфер - выходной порт занят
Innokentiy
и так происходит снова и снова, пока буфер не забьется
Innokentiy
вот те кадры, которые не удалось сложить в выходной буфер, с ними свитч ничего не может сделать, кроме как тупо дропнуть
Innokentiy
он не виноват, что ему напихали в сторону С слишком много кадров
Dmitry
он не виноват, что ему напихали в сторону С слишком много кадров
Может быть, в таком случае, расскажете как работает flow-control и back-pressure?
Innokentiy
может быть
Innokentiy
примерно туда же относятся DCB и его друзья
Innokentiy
когда свитч понимает, что некто в какой-порт пихает слишком много, он может послать этому некто сообщение «притормози»
Innokentiy
((предпоагается, что эти сообщения достаточно быстро дойдут до источника/-ов, и они это прочитают и притормозят))
Innokentiy
в хорошем случае свитч это сделает до того, как буфер заполнится, а сообщение успеет дойти до источника/-ов, и источник/-и успеют отреагировать и притормозить, так что по пути ничего в итоге не потеряется
Innokentiy
в реальности абсолютный 100% lossless сделать все равно не выйдет, даже если упороться и купить Очень Дорогое Железо, которое позволяет настроить все Как Полагается
Innokentiy
потому что не дает ethernet полностью lossless гарантированную доставку, это прям в интро стандарта написано
Innokentiy
даже прописаны конкретные потери для разных медиа, которые считаются нормой
Innokentiy
а если оно может потеряться даже в проводе, что уж говорить о транзите
Innokentiy
ну и в реальности, если мы говорим не про Очень Дорогое Железо, а про обычный flow control, это все срабатывает, когда уже начинаются дропы
Dmitry
в хорошем случае свитч это сделает до того, как буфер заполнится, а сообщение успеет дойти до источника/-ов, и источник/-и успеют отреагировать и притормозить, так что по пути ничего в итоге не потеряется
Я немного не понимаю, так все же стоит использовать flow-control?
Dmitry
Или таки, лучше отключить?
Innokentiy
смотря что за результат нужно получить
Innokentiy
обычный flow control очень редко приносит пользу, он слишком грубо работает
Innokentiy
продвинутые штуки типа pfc могут быть полезны (в предположении, что все соответственно маркируется, и железо в это умеет)
Innokentiy
если говорить про сторадж и dcb, то там подобные штуки крайне полезны, если не сказать необходимы
Dmitry
продвинутые штуки типа pfc могут быть полезны (в предположении, что все соответственно маркируется, и железо в это умеет)
Ок, понятно ... А тот же back-pressure, чем отличается от flow-control ?
Dmitry
Угу... Вроде это развитие flow-сontrol ....
Innokentiy
flow-control - технология (или класс технологий), предусматривающая отправку сообщений «притормози»
Innokentiy
back-pressure - общее название ситуаций, в которой происходит попытка впихнуть невпихуемое
Innokentiy
это не конкретная технология
Innokentiy
Innokentiy
вот те кадры, которые не удалось сложить в выходной буфер, с ними свитч ничего не может сделать, кроме как тупо дропнуть
и это тоже пример, но уже другой
Innokentiy
в первом случае прибежало больше кадров (два), чем мы могли одновременно отправить в среду (один)
Dmitry
вот это - пример back pressure
Эмм ... Все равно не очень понимаю, вот есть c9500 там есть flow-control и back-pressure раздельно... Надо гуглить конкретную реализацию ?
Innokentiy
я не знаю
Innokentiy
возможно, в конкретной железке это обозначение имеет какой-то более конкретный смысл
Dmitry
Все мои попытки заигрывания с этими 'технологиями' заканчивались просто драматичной потерей пропускной способности ... Но это наверное я кривой :(
Innokentiy
flow-control это почти наверняка обычный 802.3х, от него больше вреда, чем пользы
Innokentiy
он, грубо говоря, тупо по всему дереву отстреливает порты в сторону перегрузки