Перейти к содержимому
Калькуляторы

wtyd

Активный участник
  • Публикации

    524
  • Зарегистрирован

  • Посещение

О wtyd

  • Звание
    Аспирант
  1. proxmox 5 с drbd

    Попробуйте указать в конфиге отсутствующую ноду, которая потом появится у вас. Т.е. наверное для 10.10.10.2 добавить секцию.
  2. proxmox 5 с drbd

    Покажите, что в конфиге-то ?
  3. PIM Hello и Assert

    Поведение пустых ACL может отличаться от места применения, если вешается как ACL на интерфейс то трафик не блокируется (то есть будто ACL не назначали). В случае с neighbor-filter может быть такая же история: пустой ACL не влияет на соседства. С mvr не сталкивался, нормально ли описанное вами не скажу. И для диагностики проблем с мультикастом лучше включать дэбаг pim'а, сэкономите часы времени, настолько причины ошибок или непонятного поведения порой бывают неожиданны. На самом деле на других маршрутизаторах (там похожая конфигурация mvr влана) этот ACL содержит deny any. В "sh ip pim nei" никогда левых нейборов никогда не было, т.е. скорее всего этот расколбас делается своими же нейборами. acl я заполню, но чё-то пока кардинальных изменений вообще нет, только после перевода в читый sparse-mode пачки пакетов исчезли, но асерты всё равно есть и непонятно, чем они вызваны. На счёт дебага: есть опасения потерять управление при включении любого дебага :-). Его же нельзя на 5 минут включить, чтобы он потом сам отключился. Ничего страшного не будет ? А то ответственная железка и идти до неё не близко. Ещё такой вопрос: может ли этот расколбас быть из-за потерь в сети ? Я конечно на мониторинг всё уже поставил, потерь не задетектил, ошибок на интерфейсах нет, но может быть я что-то упустил.
  4. PIM Hello и Assert

    Конечно могут, только пакеты 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. Кваггу я ставил, чтобыв дебаге узнать причину ассертов, но не узнал ...
  5. PIM Hello и Assert

    Поменял везде, где нашёл, на sparse, пока что пачек пакетов не видел, но единичные hello и asert есть. Так что есть разница между sparse-dense и sparse (может быть времени мало прошло и они ещё прилетят :-)). Hello раз в 30 секунд или на каждый assert, а assert стали не часто и по одному прилетать. Прилетает всё это действительно скорее всего через mvr. Интересно, клиенты могут поафектить своим пимом или нет ? Ещё пробовал на mvr влане убирать pim и вместе с ним пропадает igmp snooping, т.е. перестаёт показывать. Так и должно быть или надо как-то по-другому сделать ? В mvr влане роутеров мультикаста нет и источников тоже, есть только абоненты.
  6. PIM Hello и Assert

    Ну тутпросто так было сделано, пока не ясно почему. Либо это действительно было надо, либо просто забыли или не знали, что надо отключать. Все Hello и Assert летят от маршрутизатора сети, т.е. не от разных, а от одного, который и есть главный (судя по сорс маку). Посмотрел: pim на клиентском интерфейсе выключен, скорее всего он через mvr залетает. Т.е. клиенты на него поаффектить не могут, но на него что-то другое аффектит значит. И ещё почему-то везде включено ip pim sparse-dense-mode, ip pim sparse-mode только в одном месте включено. почему так, пока нет возможности спросить, знающие люди в отпуске.
  7. В сети есть mvr. Заметил, что временами в клиентский порт прилетает пачка PIM Hello и PIM Assert. Т.е. обычно только PIM Hello раз в 30 секунд прилетает, но потом бац и 70 пакетов за секунду, а может и больше, прилетает Hello и Assert в перемешку через одного. Смотрел вирешарком, соержимое разное, значит не петля. Есть подозрение, что в такие моменты каналы подсыпаются. Что это может быть ?
  8. Что за роскмсвобода ? У вас есть 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 -- надо вообще всё блокировать по идее.
  9. После изменения способа подключения сервера (мультикаст подали в отдельном влане) перестала работать запись каналов по расписанию (пользователь на пульте включает запись и потом смотрит). Показывает, что идёт запись, но потом при попытке посмотреть выдаёт "Сервер недоступен" и всё, файлик нулевой длины создаётся. Сейчас вот такая конфигурация: 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 запросы куда-то не туда улетают или их никто не шлёт ?
  10. Доброго времени. Может кому-нибудь будет полезно. Еще один вариант [рабочий] полисера на TC. Недостаток, нельзя выделить одно полосу для нескольких ip, как в HTB (Хотя может я и не разобрался до конца). /sbin/tc qdisc add dev bond0.628 ingress /sbin/tc f a dev bond0.628 parent ffff:0 prio 10 handle 3: protocol ip u32 divisor 256 /sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 800:: match ip dst 192.168.64.0/18 hashkey mask 0x000000ff at 16 link 3: /sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.120.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :12 /sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x62: match ip dst 192.168.120.98 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :13 Не совсем понял этот пример. последний октет адреса является ключом к хешу, т.е. ойпи 192.168.120.98 попадает в 3:0x62 (98 = 0x62), а зачем тогда ещё один матч делать ? Т.е. зачем нужна запись "match ip dst 192.168.120.98" ведь пакет и так уже попал в 3:0x62, может без матча будет работать ? Если без этого матча будет работать, то ещё несколько процессорных тактов освободится. На самом деле я правда не знаю, я такое несколько лет назад на htb и затем на hfsc делал, но уже всё забыл.
  11. Cisco SCE и РКН

    С точки зрения Яровой -- да, мы должны всё, что она с товарищами напридумывали и подразумели. Либо мы должны платить бабло, т.е. штрафы. Что касается SCE, то это оборудование создавалось не для реализации законопроектов Яровой, а для другого -- там не было целей фильтровать трафик в ситуации активного противодействия этому :-). Т.е. просто фильтровать SCE может, а когда записи в реестр вносят не всегда и не совсем адекватные "специалисты", то 100% фильтрации получить невозможно. Надо ещё постоянно следить за этими записями и за "специалистами". Так же у SCE есть ограничения, которые рано или поздно будут достигнуты этими "специалистами": слишком много записей в реестр будет добавлено, слишком длинные url будут добавлены, слишком неадекватные записи будут добавлены ... да мало ли чего ещё из непредусмотренного может случиться ? :-). SCE же не всё может ...
  12. edgecore3510-28T

    Забыл добавить что когда свич вис на него и по консоли не достучишься. Нет управляющий и абонентов вланы разные. 1 влан вообще не используем. Конфигурим через консоль. После замены свичей на новые, уже пол года без нареканий работают. На всех обновил прошивку до 1.5.1.18. Полет нормальный. :-) Виснут они из-за утечек памяти -- консоль при этом тоже не работает. Утечки памяти у них в ДНК -- их копипастят китайцы из старого кода в новый, как я уже говорил -- из кода для старых свичей в код прошивок для новых моделей. Потому чтоу них одни и те же баги были замечены в разных моделях, которые на совсем разных чипсетах были сделаны. Утечки там есть и вряд ли их оттуда уберут. Значит надо делать так, чтобы в ЦПУ как можно меньше попадало трафика. Ещё было замечено, что у одной модели (ES3528M) одной h/w вершн было разное поведение, но это касалось diag кода: после одновления diag и reload все свичи загружались и работали, но после ребута по питанию больше половины не загружалось, но остальные загружались и работали нормально. Седых волос на голове у меня тогда стало на много больше чем было до этого :-), сильно я не мог экспериментировать собирать статистику, просто очень быстро поменял везде diag на прежнюю версию и больше никогда его удалённо не апгрейдил. Этот факт позволяет нам сделать вывод, что свичи в пределах одной модели и одной h/w version всёравно могут аппаратно отличаться. Завод изготовитель оставляет за собой право вносить изменения в конструкцию ... (с). А может у вас порсто дефектные свичи попались :-). Первый влан у ТС в тектовом файлике фигурирует, поэтому я про него и написал. У меня были 3528М с аптаймами больше года и это были не access свичи, за ними ещё было несколько свичей и клиенты в них тоже были включены.
  13. edgecore3510-28T

    Если вы не обновляли прошивку, то рискну предположить, что вы и настраивали свичи не вполне достаточно ? может у вас влан управления и клиентский влан это один и тот же влан ? Может вы используете влан 1 ? Может вы их по веб-морде конфигурите ? Может вы spanning-tree оставляете с настройками по-умолчанию ? Да там столько всего может быть, что лучше вам начать пкоазывать конфиги свичей, которые виснут, и рисовать схемы :-). Вот чё это за хрень ? interface ethernet 1/25 switchport allowed vlan add 1 untagged switchport mode trunk switchport allowed vlan add 1,178,195,199,419 tagged Вот так надо аплинк настраивать: interface ethernet 1/26 switchport mode trunk switchport ingress-filtering #1 switchport allowed vlan add 18,936 tagged switchport allowed vlan remove 1 #4 spanning-tree edge-port #2 spanning-tree spanning-disabled spanning-tree bpdu-filter spanning-tree tc-prop-stop mvr domain 1 type source #3 #1 - без этой команды все неизвестные свичу вланы будут влетать ему в ЦПУ и ему будте "бо-бо" #2 - использовать спаннинг три в ежах не хочешь ты #3 - ну это если ойпи-тэвэ есть #4 - Первый влан нахер из сети выкорчёвываем -- потому что он для любого оборудовани дефолтный, можно наошибаться и получить кучу глюков, а если вы его использовать перестанете, то вы все вланы сконфигурите и скорее всего правильно - наошибаться вероятность меньше. Есть ещё другие причины, по которым использование влана номер один является показателем некомпетентности администраторов сети.
  14. edgecore3510-28T

    +1. У ежей это из поколения в поколение передаётся ;-). Там разработчики баги копипастят из предыдущего софта. Надо чтобы им в проц летело как можно меньше -- отключайте все подряд ненужные фичи, которые выполняются в ЦПУ (stp, lldp и т.п., снупинги, фигупинги, вообще всё, без чего сможете жить) , смотрите, что у вас летает в влане управления, сегментируйте управление, чтобы там меньше всяких броадкастов летало, ставьте на edge, на core не ставьте ;-). Ну если уж совсем быстро надо, то для начала отключите spanning-tree на порту вышестояшего мутатора для цепочки из ежей.
  15. Пожалуйста, ткните носом дайте ссылку на требования к железу для extfilter -- надо собрать сервер (наконец-то!). На сколько я помню, нужно N сетевых карт из списка поддерживаемых http://dpdk.org/doc/nics (наверное лучше Intel карты) для зеркала и ещё минимум одну для работы с по сети, по одному ядру на карту для зеркала + сколько-то ядер под ОС. Я всё правильно перечислил или есть ещё какие-то особенности ?