[WY6EPT]

Столкнулся с ситуацией не проходят ARP через EoIP

MAC learning проходит только со стороны RB931-2nD

в обратную сторону ARP не идёт даже если на RB1100AHx2 включен proxy-apr на бридже

соответственно когда из сети виртуалку попинговали, виртуалка узнала о машине за мостом, то она эту машину начинает бодро пинговать, пока мак не забудет =)

адресация в этом сегменте на микротиках отсутствует.

при этом на RB931-2nD иногда выходит сообщение eoip-tunnel-to-tc transmit loop detected, downing interface for 60 seconds.

а сетевое оборудование за RB931-2nD через 10-30 минут встаёт колом и перестаёт как либо пропускать трафик.

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

 

Схема такая:

для адресации EoIP связности поднимается L2TP соединение, т.к. микротик стоит за NAT

Схама связности RB931-2nD - switch(internal net) - Dlink DFL800(NAT)-ISP----ISP-RB1100AHx2-Виртуальная Машина

Схема L2 сегмента ether2-Bridge-Eoip---Eoip-Bridge-Vlan1007 over Ether6

RB1100AHx2

config

name="BR_CLi007" mtu=auto actual-mtu=1500 l2mtu=1594 arp=enabled arp-timeout=auto 

     mac-address=D4:CA:6D:EA:4D:BE protocol-mode=none fast-forward=yes igmp-snooping=no 

     auto-mac=yes ageing-time=5m vlan-filtering=no dhcp-snooping=no 

 

 #     INTERFACE         BRIDGE         HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON

 0     vlan_cli007       BR_CLi007             1     0x80         10                 10       none

 1     eoip-cli007       BR_CLi007             1     0x80         10                 10       none

 

 0 R vlan_cli007                           1500 enabled            1007 ether6_VMRouting

 

RB931-2nD

config

 0 R name="bridge1" mtu=auto actual-mtu=1500 l2mtu=1598 arp=enabled 

     arp-timeout=auto mac-address=CC:2D:E0:17:65:D4 protocol-mode=none 

     fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m 

     vlan-filtering=no dhcp-snooping=no 

 

#     INTERFACE      BRIDGE         HW  PVID PR  PATH-COST INTERNA...    HORIZON

 0   H ether2         bridge1        yes    1 0x         10         10       none

 1     eoip-tunnel... bridge1               1 0x         10         10       none

при этом от RB931 всё пингует сразу, а от RB1100AHx2 в лучшем случае с 15-20 пакета оживает, а то и вообще не поднимает.

и фиг бы сним, ARP могу в виртуалке руками прописать, но ведь эта связка мне ещё умудряется сеть ложить 

 

Вот думаю, либо руки из жопы либо где?

Edited February 22, 2019 by WY6EPT

[McSea]

@WY6EPT 

Какие версии RoS ?   

Не пробовали loop protect отключить на eoip ?

 

Arp запросы со стороны виртуалки на vlan_cli007, бридж попадают ?

 

Edited February 22, 2019 by McSea

[LostSoul]

бывало подобное когда маршрут к remote peer был криво прописан  ( внешний IP микротика с вторым концом туннеля )

 

[Saab95]

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

[LostSoul]

12 минут назад, Saab95 сказал:

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

насколько же должно быть маленькое mtu что через него arp не пролезало?

 

[WY6EPT]

On 2/22/2019 at 8:38 PM, McSea said:

@WY6EPT 

Какие версии RoS ?   

Не пробовали loop protect отключить на eoip ?

 

Arp запросы со стороны виртуалки на vlan_cli007, бридж попадают ?

 

 

RoS что самый свежий =)

loopprotect как ни старнно выключен по дефолту, но мы выключили принудительно после того, как увидели сообщение в логах ( сеть ложится в независимости от этой настройки).

ARP со стороны виртуалки прилетают тегом в VLAN интерфейс и заворачиваются в бридж.

 

 

On 2/22/2019 at 9:01 PM, LostSoul said:

бывало подобное когда маршрут к remote peer был криво прописан  ( внешний IP микротика с вторым концом туннеля )

 

всё бы хорошо, но мы имеем дело с тоннелем L2tp поверх которого уже едет EoIP, само явление L2tp Тут из-за чудозверя DFL который NAT делает и ip внешний у конторы один.

так бы проблем не было

 

22 hours ago, Saab95 said:

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

mtu везде точно интернетное, то бишь не более 1500. причёт с учётом pppoe со стороны dfl и l2tp и ipsec,  то реальное MTU и того меньше.

маршруты по интернету одинаковые.

но данные то летят, связность есть. коннекты есть, но только изнутри сетки. и сама сеть ложится через 5 минут работы.

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

всё работает, провайдер тот же.

 

Edited February 24, 2019 by WY6EPT

[LostSoul]

1 час назад, WY6EPT сказал:

всё бы хорошо, но мы имеем дело с тоннелем L2tp поверх которого уже едет EoIP, само явление L2tp Тут из-за чудозверя DFL который NAT делает и ip внешний у конторы один.

это какое-то адово извращение.

на вашем DFL  нету возможности сделать редирект по типу ip-протокола?

Мне во многих случаях помогало правило типа такого , что если типа протокола 47 ( gre ) и  source ip = <наш удаленный пир>   то направляем такой трафик на внутренний IP такой-то.

Это почти всегда позволяет поднять  EOIP нормально без всяких L2TP.

 

 

С учетом описанного, думаю ваши проблемы в ipsec.  Что то там кривовато пролонгируется. возможно из-за того что не туда заворачивается какой-то нат после поднятия туннеля .  то есть после поднятия eoip нарушается процесс обновления ключей ( пытается идти не через тот интерфейс/маршрут )

 

вам он там вообще нужен, ipsec этот?

 

[WY6EPT]

21 minutes ago, LostSoul said:

это какое-то адово извращение.

на вашем DFL  нету возможности сделать редирект по типу ip-протокола?

Мне во многих случаях помогало правило типа такого , что если типа протокола 47 ( gre ) и  source ip = <наш удаленный пир>   то направляем такой трафик на внутренний IP такой-то.

Это почти всегда позволяет поднять  EOIP нормально без всяких L2TP.

 

 

С учетом описанного, думаю ваши проблемы в ipsec.  Что то там кривовато пролонгируется. возможно из-за того что не туда заворачивается какой-то нат после поднятия туннеля .  то есть после поднятия eoip нарушается процесс обновления ключей ( пытается идти не через тот интерфейс/маршрут )

 

вам он там вообще нужен, ipsec этот?

 

как раз из-за ipsec все пляски с бубном.

но мы пробовали и без него, результат идентичный.

мы поняли, что система точно работает? т.к. в третьем офисе всё отлично.

возник только один момент, при пинге 1500 байт без фрагментации из виртуалки ругается, при этом mtu на всём протяжении выставлен 1500

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

 

ну и собственно видимо вайршарк нам поможет, почему ложит весь l2 сегмент в офисе =)

Edited February 24, 2019 by WY6EPT

[LostSoul]

8 минут назад, WY6EPT сказал:

возник только один момент, при пинге 1500 байт без фрагментации из виртуалки ругается, при этом mtu на всём протяжении выставлен 1500

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

Ну вы вообще на пальцах понимаете как eoip работает?

Сетевое устройство берет ваш ethernet кадр размером , дописывает в начало свои собственные заголовки размером 28-42 байта  ( лень вспоминать сколько в точности ), и естественно что если полученный результат ( с приписанным заголовком ) в 1500 не укладывается , то ему приходится нарубить пакет на части, а потом на обратной стороне EOIP собрать.

 

А сколько там добавляет ваш l2tp / ipsec даже думать не хочется.

 

Правило работы с туннелями - очень простые. 

1) там где можешь обойтись без туннеля , обойдись без туннеля  ( не всегда, но чаще всего )

2) если вынужденно делаешь какое-то туннелирование  , обойдись одним туннелем

3) если одним туннелем обойтись не получается думай над сменой технологии туннеля

продергивать eoip через l2tp это демонстрация полной проф. непригодности человека  , который это делает

 

 

[Saab95]

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

Если будет нарушаться очередность следования пакетов, то тоже работать не будет.

Если есть IPSEC то тоже много возможностей для проблем.

Если кроме микротика в транспорте участвуют какие-то другие устройства, работает НАТ и т.п. - тоже источник потенциальных проблем.

[WY6EPT]

2 hours ago, LostSoul said:

Ну вы вообще на пальцах понимаете как eoip работает?

Сетевое устройство берет ваш ethernet кадр размером , дописывает в начало свои собственные заголовки размером 28-42 байта  ( лень вспоминать сколько в точности ), и естественно что если полученный результат ( с приписанным заголовком ) в 1500 не укладывается , то ему приходится нарубить пакет на части, а потом на обратной стороне EOIP собрать.

 

А сколько там добавляет ваш l2tp / ipsec даже думать не хочется.

 

Правило работы с туннелями - очень простые. 

1) там где можешь обойтись без туннеля , обойдись без туннеля  ( не всегда, но чаще всего )

2) если вынужденно делаешь какое-то туннелирование  , обойдись одним туннелем

3) если одним туннелем обойтись не получается думай над сменой технологии туннеля

продергивать eoip через l2tp это демонстрация полной проф. непригодности человека  , который это делает

 

 

Условия дисктуют, каким образом делать то или иное.

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

пригодность или нет не из этой темы дискуссии =)

к тому же оно работает.

а IPSEC изолируетвнутренности EoIP от вмешательства в пакет всяких проиприетарных вещей. 

вот вам пример, по туннелю между цодами не ходил OSPF.

оказалось, что мега железка цода изымала из пакета данные OSPF, вендор ничего с этим сделать не смог.

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

 и да, не считайте байты, если нужно я посчитаю.

в данной ситуации я больше обращаюсь к опыту коллег, кто сталкивался с падением всего L2 активного оборудования из-за одного EoIP до виртуалки, остальное решаемо

 

[LostSoul]

3 минуты назад, WY6EPT сказал:

в данной ситуации я больше обращаюсь к опыту коллег, кто сталкивался с падением всего L2 активного оборудования из-за одного EoIP до виртуалки, остальное решаемо

 

вы ничего там в логах на микротике вроде "bridge port received packet with own address as source address probably loop"  не ловите?

 

[WY6EPT]

2 hours ago, Saab95 said:

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

Если будет нарушаться очередность следования пакетов, то тоже работать не будет.

Если есть IPSEC то тоже много возможностей для проблем.

Если кроме микротика в транспорте участвуют какие-то другие устройства, работает НАТ и т.п. - тоже источник потенциальных проблем.

пакеты точно проходят одинаковой последовательности. мы специально проверяли.

mtu на самом L2 установлен в 1500, оно в любом случае на полном фрейме фрагментируется.

ipsec мы исключали, грабли с ARP остались.

и как бы хрен с ним с ARP, через 5 минут после включения укладывается весь L2 сегмент подключенный к eoip микротика.

как только микрот вырубается, работа нормализуется.

я больше сейчас с этой загадкой борюсь.

та же схема в другом офисе с тем же провайдером но другим маршрутизатором работает прекрасно.

 

6 minutes ago, LostSoul said:

вы ничего там в логах на микротике вроде "bridge port received packet with own address as source address probably loop"  не ловите?

 

eoip-tunnel-to-tc transmit loop detected, downing interface for 60 seconds

это единственное сообщение в логах, которое мы видим.

поэтому уже подключен wireshark и идет разбор, что к нам прилетает.

[LostSoul]

11 минут назад, WY6EPT сказал:

eoip-tunnel-to-tc transmit loop detected, downing interface for 60 seconds

это единственное сообщение в логах, которое мы видим.

поэтому уже подключен wireshark и идет разбор, что к нам прилетает.

так я и думал.

отложите свой wireshark пока и проверьте внимательно все маршрутные таблицы - что куда и как у вас идет с eoip в состоянии running и в неактивном.

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

ну то есть например, маршрут к внешнему IP удаленного роутера   оказывается достижим через eoip и возникает бесконечное кольцевание пакета с бесконечным ростом его размера ( к пакету приписывает заголовок, пихает в туннель,   снова появляется пакет для отправки через eoip , к нему еще раз приписывает заголовок и так по кругу )

 

 

 

другой вариант - посмотрите arp таймаут с обоих сторон.

не может ли получаться , что после подьема eoip интерфейса устройство начинает отвечать на arp запрос "вне туннеля" не тем mac , который вне, а который внутри?  в этом случае можно примерно обьяснить почему оно сначала работает ( пока в кеше arp висит значение услышанное "до подьема туннеля")  , а после перезапроса начинается кольцевание трафика так как в arp ответе не тот MAC

 

 

[WY6EPT]

5 minutes ago, LostSoul said:

так я и думал.

отложите свой wireshark пока и проверьте внимательно все маршрутные таблицы - что куда и как у вас идет с eoip в состоянии running и в неактивном.

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

ну то есть например, маршрут к внешнему IP удаленного роутера   оказывается достижим через eoip и возникает бесконечное кольцевание пакета с бесконечным ростом его размера ( к пакету приписывает заголовок, пихает в туннель,   снова появляется пакет для отправки через eoip , к нему еще раз приписывает заголовок и так по кругу )

 

 

как писалось в шапке, сам EoIP тоннель не имеет адресации вообще, адресация .

L2tp связность не знает ничего о оборудовании за NAT? поэтому кольцо на этом уровне исключено, иначе оно бы и ругалось.

то есть маршрутизации кроме как интернета нет.

 

[LostSoul]

ну что значит нету.

у вас есть как минимум IP адреса на сетевых езернет интерфейсах и IP  , и IP адреса на L2TP endpoint   , значит уже можно зароутить адрес из первой пары , через адрес второй пары.

 

[WY6EPT]

9 minutes ago, LostSoul said:

ну что значит нету.

у вас есть как минимум IP адреса на сетевых езернет интерфейсах и IP  , и IP адреса на L2TP endpoint   , значит уже можно зароутить адрес из первой пары , через адрес второй пары.

 

ну то есть микротик стоящий у виртуалки понятия не имеет об адресном пространстве внутри L2

оба  микротика имеют только дефолтный маршрут в интернет

[LostSoul]

4 минуты назад, WY6EPT сказал:

ну то есть микротик стоящий у виртуалки понятия не имеет об адресном пространстве внутри L2

Вы приводите конкретный список железа.

RB931-2nD и  RB1100AHx2

 

какой из них - виртуалка?

 

[WY6EPT]

4 minutes ago, LostSoul said:

Вы приводите конкретный список железа.

RB931-2nD и  RB1100AHx2

 

какой из них - виртуалка?

 

там ещ и схематичная связность. 1100 коннектит к виртуалке

[LostSoul]

В 22.02.2019 в 15:56, WY6EPT сказал:

для адресации EoIP связности поднимается L2TP соединение, т.к. микротик стоит за NAT

Схама связности RB931-2nD - switch(internal net) - Dlink DFL800(NAT)-ISP----ISP-RB1100AHx2-Виртуальная Машина

Схема L2 сегмента ether2-Bridge-Eoip---Eoip-Bridge-Vlan1007 over Ether6

RB1100AHx2

прочитал внимательно этот абзац.

Какие настройки для статического проброса 47 протокола сделаны на DFL800 ?

В вашем описании не отмечено откуда и куда поднимается l2tp

 

[WY6EPT]

5 minutes ago, LostSoul said:

прочитал внимательно этот абзац.

Какие настройки для статического проброса 47 протокола сделаны на DFL800 ?

В вашем описании не отмечено откуда и куда поднимается l2tp

 

ну т.к. в данном случае DFL натит весь траффик, то единственно возможный вариант, это 931 микрот подминает тоннель до 1100, т.к. только он имеет реальный адрес интернета

пока развлекаемся wiresharkом и смотрим логи на DFL

[LostSoul]

3 минуты назад, WY6EPT сказал:

ну т.к. в данном случае DFL натит весь траффик, то единственно возможный вариант, это 931 микрот подминает тоннель до 1100, т.к. только он имеет реальный адрес интернета 

пока развлекаемся wiresharkом и смотрим логи на DFL

ну это вы так думаете, что он единственный.

я пока вообще не понимаю зачем вообще вам EOIP и что мешает поднять просто какой-нибудь GRE прямо с DLF800 на rb1100 и на этом успокоится.

 

 

Админов,   постоянно желающих что-то куда-то туннелировать, надо бить по рукам пока они маленькие.

 

[WY6EPT]

4 minutes ago, LostSoul said:

ну это вы так думаете, что он единственный.

я пока вообще не понимаю зачем вообще вам EOIP и что мешает поднять просто какой-нибудь GRE прямо с DLF800 на rb1100 и на этом успокоится.

 

в общем и целом пока мы не отловим глюк, мы цепляемся vpn из виртуалки напрямую к dfl.

но это скорее исключение из правил.

ищем причину. потому, что все прекрасно работает в такой же конфигурации из других мест.

[LostSoul]

6 минут назад, WY6EPT сказал:

в общем и целом пока мы не отловим глюк, мы цепляемся vpn из виртуалки напрямую к dfl.

но это скорее исключение из правил.

ищем причину. потому, что все прекрасно работает в такой же конфигурации из других мест.

Я вижу, что вы пытаетесь решить какую-то вставшую перед вами задачу "через жопу".

И то что вы делаете - неправильно и безграмотно.

 

Но допустим, вам реально нужен позарез именно EOIP между двумя микротиками.

Вы пробовали поднять его напрямую без всякого L2TP?

На 931 ставите remote ip -- "белый адрес"  RB1100 .

На RB1100 ставите remote ip -  внешний NAT IP того провайдера, к которому подключен DFL800

работает?

 

[McSea]

6 hours ago, WY6EPT said:

ARP со стороны виртуалки прилетают тегом в VLAN интерфейс и заворачиваются в бридж.

Это вы сниффером на микротике видите ?  А ответ с другой стороны видите ?

 

Если нужен EoIP over IPsec, L2TP лишний.