Jump to content
Калькуляторы

wtyd

Активный участник
  • Content Count

    530
  • Joined

  • Last visited

About wtyd

  • Rank
    Аспирант
  1. Ну вообще воде можно, но я не пробовал :-). У меня нет цыскиного DMVPN. У меня пока что-то не очень понятное с несколькими хабами получается. Один тушу и какой-то расколбас в сети появляется, пока непонятно, как хабы между собой конфигурить надо.
  2. Получилось запустить на 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 проходит и надо заново резолвить. безопасность ... её нет, т.е. надо ойписекас делать.
  3. Потому что иначе регистрация в хабе вообще не происходит, я пробовал. Еще в примерах frr именно так указано делать (http://docs.frrouting.org/en/latest/nhrpd.html). Про какие ноуты идет речь ? Такое ощущение, что mgre + nhrp только на цысках работает. opennhrp последний релиз от 2013 года, а в рассылке к нему пишут про требование ARPD со стороны ядра. В том-то и дело, что рабочих современных экзамплов найти не могу.
  4. Всем привет. Есть задача сделать 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 на линуксах ?
  5. Спасибо, вроде бы работает, если в /etc/iproute2/rt_tables прописать тыщу таблиц. По крайней мере добавлять и потом смотреть получилось, дальше пока не тестировал :-).
  6. Всем привет. Столкнулся с потенциальной проблемой масштабирования PBR в linux. Обще известное решение выглядит примерно так: пишем ip rule которое матчит, например, сорс ойпи пакета и в качестве экшн направляется в какую-то таблицу маршрутизации посмотреть default gw или что там еще будет. Вроде бы ничего другого кроме таблицы там указать-то и нельзя. Таблиц в ядре очень много (https://serverfault.com/questions/315705/how-many-custom-route-tables-can-i-have-on-linux) но iprouter2 по каким-то причинам имеет доступ только от 0до 255 (реально от 1 до 252), остальные 2^30 недоступны. Предполагаю это пространство зарезервировано под namespace или что-то другое. В общем, надо иметь возможность сделать больше чем 255 ПБР и всё. Вопрос: что можно сделать, если мне понадобится сконфигурировать более 255 политик ? Есть ли другие хорошо поддерживаемые способы делать PBR в линукс ? P.S. Если я правильно помню, то у цыско в роут-мап тоже существует ограничение на 256 записей :-), но это не точно. Типа "если тебе нужно больше, то у тебя неправильный дизайн сети" (с) цыско. Но в данном случае дизайн никогоне интересует, надо чтобы работало и чтобы не было предела в 255 ПБР политик, ну хотя бы на порядок больше хочется :-), 255 это как-то не серьёзно в 2019 году.
  7. Попробуйте указать в конфиге отсутствующую ноду, которая потом появится у вас. Т.е. наверное для 10.10.10.2 добавить секцию.
  8. Покажите, что в конфиге-то ?
  9. Поведение пустых ACL может отличаться от места применения, если вешается как ACL на интерфейс то трафик не блокируется (то есть будто ACL не назначали). В случае с neighbor-filter может быть такая же история: пустой ACL не влияет на соседства. С mvr не сталкивался, нормально ли описанное вами не скажу. И для диагностики проблем с мультикастом лучше включать дэбаг pim'а, сэкономите часы времени, настолько причины ошибок или непонятного поведения порой бывают неожиданны. На самом деле на других маршрутизаторах (там похожая конфигурация mvr влана) этот ACL содержит deny any. В "sh ip pim nei" никогда левых нейборов никогда не было, т.е. скорее всего этот расколбас делается своими же нейборами. acl я заполню, но чё-то пока кардинальных изменений вообще нет, только после перевода в читый sparse-mode пачки пакетов исчезли, но асерты всё равно есть и непонятно, чем они вызваны. На счёт дебага: есть опасения потерять управление при включении любого дебага :-). Его же нельзя на 5 минут включить, чтобы он потом сам отключился. Ничего страшного не будет ? А то ответственная железка и идти до неё не близко. Ещё такой вопрос: может ли этот расколбас быть из-за потерь в сети ? Я конечно на мониторинг всё уже поставил, потерь не задетектил, ошибок на интерфейсах нет, но может быть я что-то упустил.
  10. Конечно могут, только пакеты PIM передаются мультикастом и пакеты PIM от абонентов (если такие приходят) вы должны видеть. Для включения маршрутизации мультикаста в вилане необходимо разрешать на нем PIM (собственно процесс PIM и создает мультикаст-маршруты чтобы трафик лился куда надо), подписка при этом может быть по PIM либо IGMP. А чтобы абоненты не влияли на ваш PIM надо на вилане включать BSR-border и настраивать ACL запрещающий PIM соседства. Это касательно циски и обычных виланов с мультикастом, в вашем случае с MVR и не-циско настройки могут быть несколько иные. На влане, который потом в других свичах является mvr теперь сделано так: ip address X.X.12.1 255.255.255.0 secondary ip address X.X.255.209 255.255.255.252 no ip redirects no ip proxy-arp ip pim neighbor-filter MC <-- пустой acl,ничего не разрешено.Просто он там был я новый не стал делать ip pim bsr-border ip pim sparse-mode ip igmp snooping mrouter interface GigabitEthernet3/29 <-- там есть источники мультиков, они просто льют поток ip igmp snooping mrouter interface GigabitEthernet3/31 ip igmp snooping mrouter interface GigabitEthernet4/9 ip igmp snooping mrouter interface GigabitEthernet4/10 ip igmp snooping mrouter interface GigabitEthernet4/27 ip igmp snooping mrouter interface Port-channel12 ip ospf database-filter all out Ещё заметил, что sh ip pim interface для этого влана выводит звёздочку, хотя NbrCount там ноль. Про звёздочку ничего ненашёл, но скорее всего это то, откуда есть потоки, так ? Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior ... X.X.255.209 Vlan13 v2/S * 0 30 1 X.X.255.209 ... neighbor-filter ничего не изменил, по-прежнему есть Hello и Assert, пачками не вылетают, но они есть на этом влане. Ещё есть подозрения, что я не там ищу... P.S. Скоре всего звёздочкой в sh ip pim interface обозначается bsr-border P.P.S. Поставил кваггу с pimd на свой комп и отключил ip pim neighbor-filter MC, не завязались квагга со свичем :-). Т.е. квагга нейбора как бы видела, а свич кваггу не видел. Видимо, с mvr всё же клиенты не могут влиять на pim. Кваггу я ставил, чтобыв дебаге узнать причину ассертов, но не узнал ...
  11. Поменял везде, где нашёл, на sparse, пока что пачек пакетов не видел, но единичные hello и asert есть. Так что есть разница между sparse-dense и sparse (может быть времени мало прошло и они ещё прилетят :-)). Hello раз в 30 секунд или на каждый assert, а assert стали не часто и по одному прилетать. Прилетает всё это действительно скорее всего через mvr. Интересно, клиенты могут поафектить своим пимом или нет ? Ещё пробовал на mvr влане убирать pim и вместе с ним пропадает igmp snooping, т.е. перестаёт показывать. Так и должно быть или надо как-то по-другому сделать ? В mvr влане роутеров мультикаста нет и источников тоже, есть только абоненты.
  12. Ну тутпросто так было сделано, пока не ясно почему. Либо это действительно было надо, либо просто забыли или не знали, что надо отключать. Все Hello и Assert летят от маршрутизатора сети, т.е. не от разных, а от одного, который и есть главный (судя по сорс маку). Посмотрел: pim на клиентском интерфейсе выключен, скорее всего он через mvr залетает. Т.е. клиенты на него поаффектить не могут, но на него что-то другое аффектит значит. И ещё почему-то везде включено ip pim sparse-dense-mode, ip pim sparse-mode только в одном месте включено. почему так, пока нет возможности спросить, знающие люди в отпуске.
  13. В сети есть mvr. Заметил, что временами в клиентский порт прилетает пачка PIM Hello и PIM Assert. Т.е. обычно только PIM Hello раз в 30 секунд прилетает, но потом бац и 70 пакетов за секунду, а может и больше, прилетает Hello и Assert в перемешку через одного. Смотрел вирешарком, соержимое разное, значит не петля. Есть подозрение, что в такие моменты каналы подсыпаются. Что это может быть ?
  14. Что за роскмсвобода ? У вас есть dump.xml с ЭЦП, там всё написано: /usr/bin/xml2 < /path/to/dump.xml > dump.txt ... /reg:register/content/@id=441821 /reg:register/content/@includeTime=2017-02-05T13:25:50 /reg:register/content/@entryType=1 /reg:register/content/@blockType=ip /reg:register/content/@hash=4CA2BC0B54EA6F21DB521DAEA89A35B5 /reg:register/content/decision/@date=2013-05-23 /reg:register/content/decision/@number=2-1687/2013 /reg:register/content/decision/@org=суд /reg:register/content/ip=130.185.148.13 /reg:register/content/ip /reg:register/content/ip=130.185.148.12 /reg:register/content/ip /reg:register/content/ip=130.185.148.21 /reg:register/content/ip /reg:register/content/ip=130.185.148.24 /reg:register/content/ip /reg:register/content/ip=130.185.148.25 /reg:register/content/ip /reg:register/content/ip=130.185.148.29 /reg:register/content/ip /reg:register/content/ip=130.185.148.31 /reg:register/content/ip /reg:register/content/ip=130.185.148.32 /reg:register/content/ip /reg:register/content/ip=130.185.148.34 ... Объект добавлен 2017-02-05T13:25:50. Тип блокировки ip -- надо вообще всё блокировать по идее.
  15. После изменения способа подключения сервера (мультикаст подали в отдельном влане) перестала работать запись каналов по расписанию (пользователь на пульте включает запись и потом смотрит). Показывает, что идёт запись, но потом при попытке посмотреть выдаёт "Сервер недоступен" и всё, файлик нулевой длины создаётся. Сейчас вот такая конфигурация: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 90:e6:ba:71:ae:53 brd ff:ff:ff:ff:ff:ff inet X.Y.Z.88/26 brd 78.140.15.127 scope global eth0 inet6 fe80::92e6:baff:fe71:ae53/64 scope link valid_lft forever preferred_lft forever 6: eth0.14@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 90:e6:ba:71:ae:53 brd ff:ff:ff:ff:ff:ff inet 10.11.12.3/24 scope global eth0.14 inet6 fe80::92e6:baff:fe71:ae53/64 scope link valid_lft forever preferred_lft forever # ip r default via X.Y.Z.65 dev eth0 10.11.12.0/24 dev eth0.14 proto kernel scope link src 10.11.12.3 X.Y.Z.64/26 dev eth0 proto kernel scope link src X.Y.Z.88 224.0.0.0/4 dev eth0.14 scope link python dumpstream -a 233.173.129.16 -p 1234 ничегоне вываливает, но в соседней консоли видно, что на eth0.14 поток для этой группы летит. В какой момент времени начал лететь поток я не знаю, может он там и до запуска dumpstream летел :-). Т.е. пока не получается явно узнать, из-за чего перестала работать запись каналов по расписанию. Что можно сделать ? UPD: Попробовали запустить dumpstream на группу, которая там точно не летит -- ничего не полетело. tcpdump не показал ничего в том числе и igmp-запросов на эту группу. Может в этом всё и дело, что igmp запросы куда-то не туда улетают или их никто не шлёт ?