wtyd Опубликовано 15 сентября, 2019 · Жалоба Всем привет. Есть задача сделать point-to-multipoint сеть на nbma сети. Т.е. mgre + nhrp овер интернет. Как бы большая плоская сеть с кучекй нейборов в mgre. В статике всё работает, если на всех хостах прописать всех нейборов, то всё ок. Хочется динамики. Для этого вроде бы есть nhrp: ноды регистрируются на хабе (или на нескольких хабах), хабы знают про все ноды. При необходимости (как ее создать ?) нода запрашивает у хаба nbma(т.е. публичный адрес ноды в интернете) адрес, получает ответ и туннель начинает работать. Вторая нода так же узнает про первую на хабе по загадочной необходимости и у себя делает запись про нейбора (на какой-то ТТЛ) и туннель в обратную сторону тоже начинает работать. Что-то типа АРП но для гре. Так всё в теории, на виртуалках так не работает -- ноды не хотят ничего узнавать у хаба, точнее, я пока не знаю, как сказать нодам "адреса нейборов вот для этого диапазона надо узнавать у хаба, потому что он доступен напрямую через туннель". Делаю пока всё без ipsec (там столько мест, где можно ошибиться). За основу для frr и quagga взял https://github.com/FRRouting/frr/blob/master/nhrpd/README.nhrpd. Вот там как бы и нет указания на то, что именно надо "резолвить у хаба", а адреса на туннелях делаются /32, с другими масками регистрация на хабе вообще не работает. Три ноды в трёх разных ip-сетях (192.168.10{1..3}.2), гре туннели вида: iface gre1 inet static pre-up ip tunnel add $IFACE mode gre key 42 ttl 64 dev e#th0 || true address 10.0.0.{1..3} netmask 255.255.255.255 post-down ip tunnel del $IFACE || true a1# sh ru #(hab) Building configuration... Current configuration: ! frr version 7.1 frr defaults traditional hostname a1 log syslog no ipv6 forwarding ! debug nhrp all ! interface gre1 ip nhrp network-id 1 ip nhrp registration no-unique ip nhrp shortcut no link-detect tunnel source eth0 ! router bgp 65000 neighbor Q peer-group neighbor Q remote-as 65000 neighbor Q disable-connected-check bgp listen range 0.0.0.0/0 peer-group Q ! address-family ipv4 unicast network 10.0.0.0/16 redistribute nhrp neighbor Q route-reflector-client exit-address-family ! line vty ! # spoke 1 alpine2# sh ru Building configuration... Current configuration: ! frr version 7.1 frr defaults traditional hostname alpine2 no ip forwarding no ipv6 forwarding ! interface gre1 ip nhrp network-id 1 ip nhrp nhs dynamic nbma 192.168.101.2 ip nhrp registration no-unique ip nhrp shortcut no link-detect tunnel source eth0 ! router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 disable-connected-check ! line vty ! end alpine2# # spoke2 alpine3# sh ru Building configuration... Current configuration: ! frr version 7.1 frr defaults traditional hostname alpine3 no ip forwarding no ipv6 forwarding ! interface gre1 ip nhrp network-id 1 ip nhrp nhs dynamic nbma 192.168.101.2 ip nhrp registration no-unique ip nhrp shortcut no link-detect tunnel source eth0 ! router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 disable-connected-check ! line vty ! end alpine3# Вроде бы рекомендуют именно так делать. В этой схеме почему-то надо чтобы первый пакет пошел через хаб, хаб бы его пророутил и послал бы nhrp-redirect, после чего на ноде возникает нейбор и туннелирование идёт напрямую минуя хаб. Один раз даже заработало (включил форвардинг и iptables правило из документации на хабе), заработало только в одну сторону, второй спок продолжал слать ответы через хаб. С opennhrp на туннелях делал /16 , геристрация вообще не работала. В сети вообще очень мало про opennhrp и он наверное мёртв (?) Вопрос: как объяснить спокам, что надо узнавать адреса нейборов на хабе и слать трафик напрямую в туннель между споками, а не через хаб ? Если есть рабочие конфиги для любых nhrp демонов, то просьба поделиться ими и нюансами в настройке. У цыски настраивается немного иначе, но в frr/quagga нет таких точно команд, а у меня нет цысок чтобы проверить :-). Может быть есть другой способ сделать point-to-multipoint на линуксах ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 15 сентября, 2019 · Жалоба Почему у вас на туннеле маска 255.255.255.255? Ну и ноуты почитайте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 15 сентября, 2019 (изменено) · Жалоба Потому что иначе регистрация в хабе вообще не происходит, я пробовал. Еще в примерах frr именно так указано делать (http://docs.frrouting.org/en/latest/nhrpd.html). Про какие ноуты идет речь ? Такое ощущение, что mgre + nhrp только на цысках работает. opennhrp последний релиз от 2013 года, а в рассылке к нему пишут про требование ARPD со стороны ядра. В том-то и дело, что рабочих современных экзамплов найти не могу. Изменено 15 сентября, 2019 пользователем wtyd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 15 сентября, 2019 · Жалоба Получилось запустить на opennhrp, дело было не в бобине ... alpine sysctl пре-сет сидел в кабине :-). После удаления sysctl файлов и ребута всех нод, opennhrp почему-то заработал, а frr так и не работает. Это портит дальнейшую перспективу для ipsec, можетне получится, т.к. opennhrp очень старый для современногос офта и инструкций пока не нашел. Кому интересно вот более менее рабочий вариант конфигов для стенда описанного выше (маски на туннельных ойпи посенял на /16 как того хочет opennhrp): a1:~# cat /etc/opennhrp/opennhrp.conf interface gre1 non-caching redirect shortcut cisco-authentication secret8 holding-time 30 interface eth0 shortcut-destination interface lo shortcut-destination alpine2:~# cat /etc/opennhrp/opennhrp.conf interface gre1 # map 10.0.0.1/16 192.168.101.2 register dynamic-map 10.0.0.0/16 192.168.101.2 shortcut redirect non-caching cisco-authentication secret8 # holding-time 30 holding-time 300 alpine3:~# cat /etc/opennhrp/opennhrp.conf #interface gre1 # map 10.0.0.1/16 192.168.101.2 register # shortcut # redirect # non-caching # cisco-authentication secret8 interface gre1 dynamic-map 10.0.0.0/16 192.168.101.2 shortcut redirect non-caching cisco-authentication secret8 holding-time 60 Ну еще закомментил все упоминания про racoonctl в файлах /etc/opennhrp/opennhrp-script, а то иначе скрипт ругался. Впечатления пока не очень, работает как-то ненадежно. Если рестартануть хаб, то ноды в нем не быстро перерегистрируются - holdtime афектит вообще на всё, протокол stateless. Когда пинг со спока на спок запускаешь, то теряется 1-3 первых пакета, пока не происходит разрешение нейбора, но зато потом вроде не теряются даже когда holdtime проходит и надо заново резолвить. безопасность ... её нет, т.е. надо ойписекас делать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 15 сентября, 2019 · Жалоба 14 hours ago, wtyd said: Может быть есть другой способ сделать point-to-multipoint на линуксах ? Я отказался от opennhrp в свое время, так-как он хотел в то время патченого ядра, а мне надо было делать на дистрибутивных. Сейчас не знаю. У меня есть небольшая, порядка 30 узлов. Поэтому у меня два узла выполняют роль хабов. При этом там ведется база в виде списка, которая просто при обновлении рассылается по нодам, где лежат скрипты, обновляющие ip ne список. Обновления рассылаются моими программными средствами, в которые встроены инструменты отслеживания обновления. Но это вообще не принципиально, можно обычным curl'ом дергать регулярно - трафик мизерный. Ну и да, маску бы поставить. А качестве ключа я использую network виртуальной сети - так не надо "запоминать" его значение, и оно выставляется "автоматически" (у меня скрипт сам "выдергивает" его). ipv6 вообще выставляются просто по isatap. Там достаточно lladdr. Если у вас сеть небольшая, то NHRP может подождать до лучших времен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 16 сентября, 2019 · Жалоба Т.е. так можно и к цисковскому DMVPN подключаться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 20 сентября, 2019 · Жалоба On 9/16/2019 at 2:21 PM, VolanD666 said: Т.е. так можно и к цисковскому DMVPN подключаться? Ну вообще воде можно, но я не пробовал :-). У меня нет цыскиного DMVPN. У меня пока что-то не очень понятное с несколькими хабами получается. Один тушу и какой-то расколбас в сети появляется, пока непонятно, как хабы между собой конфигурить надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 20 сентября, 2019 · Жалоба 11 hours ago, wtyd said: У меня пока что-то не очень понятное с несколькими хабами получается. Один тушу и какой-то расколбас в сети появляется, пока непонятно, как хабы между собой конфигурить надо. У вас замечательная возможность наловить блох в реализации хабов, и дописать туда код, что бы исправить "карманы". Если, конечно, есть условия и желание. PS А то есть ощущение, что этот протокол немного заброшенный и мало кем используемый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...