проще всего отказаться от hAP lite моя цель сейчас разобраться и понять. просто взять устройство помощнее — это выход из ситуации, но я хочу понять. Для меня это важней.

Могу предположить, что у Вас проблема с маршрутизацией на 951-м. Возможно в ГРЕ не правильно НАТится соурс.

да

вот мое начальное сообщение этого треда https://t.me/mikrotikclub/254917

Могу предположить, что у Вас проблема с маршрутизацией на 951-м. Возможно в ГРЕ не правильно НАТится соурс.

туда вообще ничего не натится. я поднял GRE и назначли айпи адрес ему. пингую с hAP lite IP адрес RB951 этого же GRE тунеля

192.168.200.1 — адрес gre на RB951 192.168.200.2 — адрес gre на hAP lite

трафика в тунеле нет вообще никакого

туда вообще ничего не натится. я поднял GRE и назначли айпи адрес ему. пингую с hAP lite IP адрес RB951 этого же GRE тунеля

Куда "туда"? Если не нравится слово НАТится, то используйте слово "префсоурсится". )

я ожидал увидеть в profiles какую-то проблему, но там всё чисто. загрузка процессора на hAP lite еле до 3% доходит.

Куда "туда"? Если не нравится слово НАТится, то используйте слово "префсоурсится". )

в тунель никакого фаервола для этого интерфейса нет вообще

ничего не маршрутируется в него вообще. это просто тунель оконеченый айпи адресами с двух сторон

в тунель никакого фаервола для этого интерфейса нет вообще

Не В туннель, а ДЛЯ туннеля.

Ребятки, а подскажите, какое реальное преимущество у gre перед, например, l2tp, если нужно организовать объединение нескольких CPE (офисов) в единую сеть с использованием OSPF. Всегда для этого использовал l2tp, а тут на объекте всё на gre и никто не знает почему используется именно gre. Очевидно, я чего-то не знаю. Буду благодарен за прояснение этого вопроса.

Ребятки, а подскажите, какое реальное преимущество у gre перед, например, l2tp, если нужно организовать объединение нескольких CPE (офисов) в единую сеть с использованием OSPF. Всегда для этого использовал l2tp, а тут на объекте всё на gre и никто не знает почему используется именно gre. Очевидно, я чего-то не знаю. Буду благодарен за прояснение этого вопроса.

l2tp это клиент сервер, gre -это точка точка. Надеюсь понятно.

l2tp это клиент сервер, gre -это точка точка. Надеюсь понятно.

это понятно. спасибо :)

не понятно преимущество

при наличии сотни торговых точек поднимать сотню gre тунелей для них и обеспечивать белые статические адреса на торговых точках платя за это дополнительные деньги. в чем смысл? почему не l2tp?

вы точки связываете ни через одну единственную точку

при наличии сотни торговых точек поднимать сотню gre тунелей для них и обеспечивать белые статические адреса на торговых точках платя за это дополнительные деньги. в чем смысл? почему не l2tp?

тут конечно бред GRE поднимать

тут конечно бред GRE поднимать

вот. значит все таки смысла нет. все равно топология "звезда" в любом случае

gre обычно используют для связи между ядрами.

gre обычно используют для связи между ядрами.

логично. вот я и хотел понять, может чего-то не знаю, почему выбрали для "звезды" именно gre оказывается просто "потому что" скорее всего :)

логично. вот я и хотел понять, может чего-то не знаю, почему выбрали для "звезды" именно gre оказывается просто "потому что" скорее всего :)

видать бывшие цискари ))

видать бывшие цискари ))

да ) так и есть

Ребятки, а подскажите, какое реальное преимущество у gre перед, например, l2tp, если нужно организовать объединение нескольких CPE (офисов) в единую сеть с использованием OSPF. Всегда для этого использовал l2tp, а тут на объекте всё на gre и никто не знает почему используется именно gre. Очевидно, я чего-то не знаю. Буду благодарен за прояснение этого вопроса.

ответ прост - оно жрет меньше CPU и обеспечивает лучшую производительность. раньше где-то wiki содержала сравнение туннельных протоколов

ответ прост - оно жрет меньше CPU и обеспечивает лучшую производительность. раньше где-то wiki содержала сравнение туннельных протоколов

что-то на хаплайте у меня l2tp обеспечивает лучшую производительсность :) но спасибо. я понял. возможно действительно из этих соображений выбирали gre чтобы использовать максимально дешевое оборудование на точках но это все равно не логично, потому что приходилось платить на всех точках дополнительно за статический белый адрес... люди — иррациональные существа :)

что-то на хаплайте у меня l2tp обеспечивает лучшую производительсность :) но спасибо. я понял. возможно действительно из этих соображений выбирали gre чтобы использовать максимально дешевое оборудование на точках но это все равно не логично, потому что приходилось платить на всех точках дополнительно за статический белый адрес... люди — иррациональные существа :)

видимо, потому что вы не бывший цискарь ;)

что-то на хаплайте у меня l2tp обеспечивает лучшую производительсность :) но спасибо. я понял. возможно действительно из этих соображений выбирали gre чтобы использовать максимально дешевое оборудование на точках но это все равно не логично, потому что приходилось платить на всех точках дополнительно за статический белый адрес... люди — иррациональные существа :)

https://rickfreyconsulting.com/mikrotik-vpns/

вот вам картинки, я но мои тесты показывают несколько большую производительность, чем указано. а вообще - плохо там все у mikrotik c VPN-ами если взглянуть на других производителей. и сейчас мне тут набегут и расскажут как все хорошо :)

https://rickfreyconsulting.com/mikrotik-vpns/

интересно а там какая скорость у них? выше 60 мбит? сомневаюсь ))) но реально если там еще фаервол и нат подцепить то выше 15 мбит вы хер получите на хап лайтах что в l2tp что в gre с IPSEC.

вот вам картинки, я но мои тесты показывают несколько большую производительность, чем указано. а вообще - плохо там все у mikrotik c VPN-ами если взглянуть на других производителей. и сейчас мне тут набегут и расскажут как все хорошо :)

Надо просто переложить это в плоскость бабла и необходимой квалификации для настройки оборудования

интересно а там какая скорость у них? выше 60 мбит? сомневаюсь ))) но реально если там еще фаервол и нат подцепить то выше 15 мбит вы хер получите на хап лайтах что в l2tp что в gre с IPSEC.

За полторы тыщи удивительно, что он включается

вот вам картинки, я но мои тесты показывают несколько большую производительность, чем указано. а вообще - плохо там все у mikrotik c VPN-ами если взглянуть на других производителей. и сейчас мне тут набегут и расскажут как все хорошо :)

люблю критическое мышление. спасибо! только что поднял для этого hAP lite специально L2TP и проблема сохраняется и на нем... пока что отбой. попробую разобраться сам

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

люблю критическое мышление. спасибо! только что поднял для этого hAP lite специально L2TP и проблема сохраняется и на нем... пока что отбой. попробую разобраться сам

Какая проблема сохраняется?

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

и стоимость выше невиданно )))

что-то на хаплайте у меня l2tp обеспечивает лучшую производительсность :) но спасибо. я понял. возможно действительно из этих соображений выбирали gre чтобы использовать максимально дешевое оборудование на точках но это все равно не логично, потому что приходилось платить на всех точках дополнительно за статический белый адрес... люди — иррациональные существа :)

>на всех точках дополнительно за статический белый адрес... люди знали что делали: - отвалился у вас туннель и все играть в луноход или ехать на объект; - пропадает масса мелких проблем связанных с натом оператора; это так на вскидку

Какая проблема сохраняется?

с задержками

а вы пинганите без впн внешние ип адреса

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

имея сумму в 500$ вы купите циску или микротик, и кто за эти деньги будет производительнее?

с задержками

Я Вам ответил. что проблема не в туннеле(не в его типе). А по поводу GRE vs L2TP - у GRE у гре выше скорость и меньше оверхед. И не путайте чистый gre и gre/ipsec

имея сумму в 500$ вы купите циску или микротик, и кто за эти деньги будет производительнее?

весь оффтоп будет вырезан, если не прекратится

>на всех точках дополнительно за статический белый адрес... люди знали что делали: - отвалился у вас туннель и все играть в луноход или ехать на объект; - пропадает масса мелких проблем связанных с натом оператора; это так на вскидку

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

а вы пинганите без впн внешние ип адреса

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

а вы пинганите без впн внешние ип адреса

вот, пожалуйста, ссылка на первое сообщение по теме https://t.me/mikrotikclub/254917

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

эххх ... нет, я использую внешние статические адреса везде или вообще прошу услуги L2/L3-VPN c гарантированными параметрами.

Я Вам ответил. что проблема не в туннеле(не в его типе). А по поводу GRE vs L2TP - у GRE у гре выше скорость и меньше оверхед. И не путайте чистый gre и gre/ipsec

Чистый GRE зачем? без шифрования? это наверное для того что бы бюджет освоить?

эххх ... нет, я использую внешние статические адреса везде или вообще прошу услуги L2/L3-VPN c гарантированными параметрами.

ну тут всё должно быть максимально дешево... доходность не позволяет делать качественно

Чистый GRE зачем? без шифрования? это наверное для того что бы бюджет освоить?

Нет, для обеспечения маршрутизации. Шифрование не всегда нужно.

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

проц на хап лайте что говорит? tools -> profile

проц на хап лайте что говорит? tools -> profile

по нулям практически

по нулям практически

очень интересно, trace сделай

проц на хап лайте что говорит? tools -> profile

вот в данный момент

очень интересно, trace сделай

куда? это точка точка с айпи на концах. и все. никакой маршрутизации нет. трафика тоже нет. голый тунель

[192.168.200.1]—-gre—-[192.168.200.2] и всё

че с ОС? какая версия стоит?

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

че с ОС? какая версия стоит?

последняя стабильная. везде на всех маршрутизаторах сети

последняя стабильная. везде на всех маршрутизаторах сети

LONG-TERM, понятие stable - это не про mikrotik

попробуй sstp поднять между ними и пропингуй

тестовый впн с левыми ип адресами без оспф

LONG-TERM, понятие stable - это не про mikrotik

не откатывался на long term но остальные устройства работают нормально ладно. тут похоже какая-то индивидуальная проблема, так как L2TP тоже точно так же лагает, но на hap lite он никогда не лагал ранее. Так что тут явно не с gre проблема и не с ipsec, а какая-то глобальная. спасибо. пока что я вопрос приостанавливаю, буду разбираться, раз такое дело

тестовый впн с левыми ип адресами без оспф

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

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

)

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

на sstp пробуй, если там будет ок, значит какой то пров тебя ограничивает по портам впн

не откатывался на long term но остальные устройства работают нормально ладно. тут похоже какая-то индивидуальная проблема, так как L2TP тоже точно так же лагает, но на hap lite он никогда не лагал ранее. Так что тут явно не с gre проблема и не с ipsec, а какая-то глобальная. спасибо. пока что я вопрос приостанавливаю, буду разбираться, раз такое дело

специально для вас: [LOCATION]: Volgograd, Test stand (tst-r0.local) [HARDWARE]: BOARD hAP / LDR 6.48.6 / ROS 6.48.6 (long-term).mipsbe #1 MIPS 24Kc V7.4 (650 Mhz) [admin@tst-r0.local] > /interface gre export terse # jan/18/2022 14:28:49 by RouterOS 6.48.6 # software id = W1QR-S6LT # # model = 951Ui-2nD # serial number = 7C260741CE52 /interface gre add comment="userconf: test gre connection" keepalive=10s,3 local-address=2.2.2.5 name=gre-tunnel1 remote-address=2.2.2.1 [admin@tst-r0.local] > put [ /ip address get [ find where interface=gre-tunnel1 ] address ] 172.29.16.2/30 — [LOCATION]: Volgograd, Test stand (tst-r1.local) [HARDWARE]: BOARD hAP mini / LDR 6.48.6 / ROS 6.48.6 (long-term).smips #1 MIPS 24Kc V7.4 (650 Mhz) [admin@tst-r1.local] > /interface gre export terse # jan/18/2022 14:28:19 by RouterOS 6.48.6 # software id = Y8LT-1QHK # # model = RB931-2nD # serial number = 94A40977B7B9 /interface gre add comment="userconf: test gre connection" keepalive=10s,3 local-address=2.2.2.1 name=gre-tunnel1 remote-address=2.2.2.5 [admin@tst-r1.local] > put [ /ip address get [ find where interface=gre-tunnel1 ] address ] 172.29.16.1/30 — [admin@tst-r0.local] > ping 172.29.16.1 size=1500 interval=100ms count=10 SEQ HOST SIZE TTL TIME STATUS 0 172.29.16.1 1500 64 1ms 1 172.29.16.1 1500 64 0ms 2 172.29.16.1 1500 64 0ms 3 172.29.16.1 1500 64 0ms 4 172.29.16.1 1500 64 0ms 5 172.29.16.1 1500 64 0ms 6 172.29.16.1 1500 64 0ms 7 172.29.16.1 1500 64 0ms 8 172.29.16.1 1500 64 0ms 9 172.29.16.1 1500 64 0ms sent=10 received=10 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=1ms [admin@tst-r0.local] > ping 172.29.16.1 size=1500 interval=100ms count=100 <SKIP> sent=100 received=100 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=1ms

собственно и с GRE+IPSec - ну воот вообще никаких проблем нет. Тест повторяет ситуацию, когда с двух сторон тип подключения IPoE, внешняя статика, между туннельными адресами ходит пакет IPv4 с MTU 1500 без фрагментации

просто / быстро / работает / позволяет управлять устройством через внешний IP-адрес в случае развала туннеля / позволяет провести ПОЛНУЮ диагностику подключения от точки до точки включения

просто / быстро / работает / позволяет управлять устройством через внешний IP-адрес в случае развала туннеля / позволяет провести ПОЛНУЮ диагностику подключения от точки до точки включения

Только еще "белые" адреса нужны. Для l2tp они не нужны

в рамках кабеля между двумя хап лайтами, если руки не кривые проблема может быть только в этом кабеле. У человека проблема между двумя регионами, а там между двумя микротик может быть от 3 до 20 маршрутизаторов операторов.

в рамках кабеля между двумя хап лайтами, если руки не кривые проблема может быть только в этом кабеле. У человека проблема между двумя регионами, а там между двумя микротик может быть от 3 до 20 маршрутизаторов операторов.

да. тут порядка 800 км на пути трафика :) но это тестовая схема. не рабочая. в рабочей схеме всё в пределах города с минимальными задержками и часто даже в сети одного оператора либо группы операторов с прямыми интерконнектами.

на самом деле это мой домашний маршрутизатор с РРРоЕ :) и второй подключен в том городе, где обслуживаемая сеть. однако у меня на моем домашнем маршрутизаторе есть другой рабочий GRE линк который работает без проблем. и когда я подключил этот тестовый hAP lite, то подумал сразу что проблема с hAP lite в плане IPSec (не тянет) но потом это опроверглось отключением IPSec а теперь уже и опроверглось то, что это с gre проблема, так как мой привычный L2TP тоже оказывается точно так же работает. может быть проблема с конкретным экземпляром hAP lite, но это как-то маловероятно.

Напрямую белые адреса между маршрутизаторами пингуются очень ровно ≈22мс практически с нулевым джиттером. вот именно изза этого и возник вопрос, почему тунели так себя ведут

на самом деле это мой домашний маршрутизатор с РРРоЕ :) и второй подключен в том городе, где обслуживаемая сеть. однако у меня на моем домашнем маршрутизаторе есть другой рабочий GRE линк который работает без проблем. и когда я подключил этот тестовый hAP lite, то подумал сразу что проблема с hAP lite в плане IPSec (не тянет) но потом это опроверглось отключением IPSec а теперь уже и опроверглось то, что это с gre проблема, так как мой привычный L2TP тоже оказывается точно так же работает. может быть проблема с конкретным экземпляром hAP lite, но это как-то маловероятно.

с микротиком бывает, так что маловероятно нужно поправить на скорее вероятно )

Напрямую белые адреса между маршрутизаторами пингуются очень ровно ≈22мс практически с нулевым джиттером. вот именно изза этого и возник вопрос, почему тунели так себя ведут

тунели грузят проц, может что не так с процом в этом экземпляре, бывает и такое

тунели грузят проц, может что не так с процом в этом экземпляре, бывает и такое

может. но по profile он простаивает

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

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

Разрешите gre явно первым правилом. Возможно тут проблема

Разрешите gre явно первым правилом. Возможно тут проблема

с l2tp такая же проблема, как выяснилось

Всем привет, почему убрали софтину netinstall нужно обновить hap lite ругается что не хватает памяти штатными средствами скачать не может , роутер сброшен и без файлов, как теперь обновить малыша

с l2tp такая же проблема, как выяснилось

Попробуйте другой микрот на том же подключении и закроем вопрос

Всем привет, почему убрали софтину netinstall нужно обновить hap lite ругается что не хватает памяти штатными средствами скачать не может , роутер сброшен и без файлов, как теперь обновить малыша

Откуда убрали?