Maika

Добрый. Ну, как говорится, хорошо. По крайней мере, порядка станет на чуть-чуть больше.

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

Всё в разы проще, предлагаю, как и вы написать им о том, что есть такая фкнкция и не хотят ли они ее а). выпилить, б). удалить, в). довести до ума. Это можно напсать как бы между делом. Основной вопрос такой - планируется ли выпуск многопортовых консольных серверов с поддержкой мультикаста. А то 2-портовки это ,конечно, круто, но они не резервирутся по питанию и их надо порой просто много, что создает некоторые неудобства. А схема по факту ни разработчику, ни вам, ни даже мне не нужна. Планируется - хорошо, будем, как говорится, ждать. Если нет, так нет. Ну а если вдруг до ума доведут функцию...ну будем тоже рады.

Схему рисовать.. ну смысл какой? По пунктам 1 и 2 будет кружок-палка-кружок. Работает, как написано в 1. и 2. - пунктах. На работоспособность влияет только тем, что система выглядит проще, в смысле количества железок, а, значит, надёжнее, а мультикастом управлять проще, если передавать его в другие сети, натить и т.п. На данный мемент 2-й пункт не реализован, а работает у кого как... где то бродкастом, где то 5000A используется (но они только2-портовые - неудобно). Мультик был бы супер.

1). RSx16->multicast->N ethernet получателей. 2). N ethernet sources -> multicast -> N RS-получателей. Предельно просто.

Не так понял. Если бы принимали так - было бы очень хорошо. А наличие рабочей функции передачи мультикастом помогает передавать информацию сразу очень многим получателям, не прибегая ко всяким перемычкам на моксе и настройкам в сети. А локаторы разные - какие то только в RS выдают, какие то в ethernet. То же и с пеленгаторами. Без мультикаста 50 получателей организовать с локатора - то еще занятие. Как мультикаст открыли - прям рай. А прием бы помог как ни странно принимать выданную локационку из других городов мультикастом и передавать ее в RS устройствам, которые в ethernet не умеют.

Могу сислог приложить без записи, а евент лог с записью, и все это с 4-х коммутаторов. Так не пойдёт?

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

Интересно даже, что сложнее для них будет - выпилить функционал или наоборот

А что! Мысль интересная. Предлагаю написать суть так: есть вот такая штука незаявленная, вот так вот работает. Преглагаем её отключить, чтоб неповадно было (а то ишь чего захотели - мультикаст за 100 т.р всего то) ну или добавить мультикаст на приём, - вот так на ваше усмотрение, ув. разрабы А то, понимашь, ни рыба, ни мясо.

Я о том и говорю. А добавить новый модуль... да, но какой же это модуль? Это не отдельный функционал даже, а улучшение старого. Едва ли там потребуется переписывать прям целый модуль/класс. Ну дело даже не в этом, бог с ним. А как насчет новых моделей? Почему такое не реализовать в них? А по поводу OSPF - была у нас тема на форуме с вами "модули расширения" называлась. Так вот там мы какую-никакую информацию до разработчиков донести смогли. Там речь шла о том, "а нельзя ли реализовать фильтрацию OSPF маршрутов на EDR-810", и с ваших слов разработчики даже обещали совещание собрать по данному вопросу и обсудить. Вот, собственно, и подумал, почему бы не донести информацию до них таким же образом. Интересно, что бы ответили они. А почему хотябы "warm restart by self diagnostic" даже в сислог не пуляется? Так задумано?

Сегодня взял моксу со склада и собрал стендик. Натравил выдачу на группу 239.50.50.1, мокса выдаёт на мак 01:00:5e:32:32:01, так что да - вполне себе мультикаст. Но не принимает.

А если стенд не собрать - как воспроизведете тогда то, что хотелось бы воспроизвести? Дамп с SNMP трафиком посмотреть тоже наверно будет полезно, но его снять, находясь в другой геолокации действительно сложно. Людей на объекте то нет. Ладно местных сгонять рубильник дернуть.

Написал я, сравнив с вашей аллегорией. Сделать в авто еще один привод (по-вашему) это же не тоже самое, что, например, сменить шины на шипованные. А чем отличается это от ситуации с OSPF? Вполне себе подобный вопрос.

Да я просто предлагаю, интересно, что разработчик скажет, ведь по поводу фильтрации OSPF на предложение хотя бы ответили. А сделать такое посложнее будет. А речь про то, что можно рассмотреть мой вариант и внедрить его, допустим, на новых моделях оборудования. Ну а там и до обновления "для крестьян с барского плеча" не далеко. Корабль и самолёт - это как раз аллегория ваша, то есть, прям переделывание девайса полностью. Я сказал, что сложно?)) Не вижу в упор, где. Я сказал "думаю, что не сильно усложнит доработку". Это не "дел на полчаса". Вы воспринимаете и тут же снова используете ваш любимый приём :), типа этого: "на улице не очень..." -> "на улице апокалипсис". По SNMP - как моё предложение насчёт тестового стенда, который я описал? Думаю, воспроизвести реально, вам же воспроизвести нужно.

Касательно CN - там как раз таки сложно понять, почему поддержка стандартной функции сетевого интерфейса сравнивается с полной переделкой девайса. Про СоS я хочу сказать то, что добавление одного пускай байта (этого вполне хватит) врятли плохо повлияет на протокол и сильно усложнит его доработку, при том его улучшит в вашу же пользу. И прокомментируйте, пожалуйста, последнее сообщение, содержащее SNMP.

Почему же? Первый вариант словно настройка влан вручную - вполне себе технология. Речь ведь не о ядре софта, а о "галочке". А второй вариант по сути содержит в передаваемой инфе лишнее поле (как CoS в vlane), например. Там пары-тройки бит хватит, зачем конфигурацию то передавать.. Активен таймер или нет, ну можно значение пихнуть (не обязательно).

Про то, активна она или нет? Ну тут двумя вариантами можно. Вариант 1-й - никак. Поведение по умолчанию, и она будет не активна, - так будет проще. Включать вручную. Вариант 2-й - передавать некоторые параметры мастера, в т.ч. и состояние активности настройки в служебных кадрах турбо-ринг, то есть все будут знать кто мастер и в каком статусе настройка если что.

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

А он и не узнает. Если он не мастер - просто она становится не активной, а все порты в "forwarding" статусе. А мастер или нет определяется изначально вручную, как сейчас.

Если не мастер - порты держим в "forward" . На мастере имеем активную настройку с таймером. Как только статус мастер переходит кому-то другому - у него становится настройка активной, а на "не мастере" нет. Так же, есть информация по непосредственно "приколам с SNMP". Продолжаются Warm reboot by self diagnostic. Раз в сутки, иногда 2-3 раза в рандомный момент. И вот.... отрубили SNMP на коммутаторах в разделе Seсurity/Management interface. И.. помогло. 3-е суток ни-ни. Всё ок. Думаю, воспроизвести реально. Например, берём собираем turbo ring v2 на 4-х свитчах IKS-6726A-2GTXSFP-T. Далее, поднимаем заббикс (для чистоты - как у нас версия 6.0). Далее настраиваем низкоуровневое обнаружение, пускай тянет к примеру описание интерфейсов (частота опроса 2 минуты). Во-первых, увидите, что их там очень много несуществующих, во-вторых, погоняв пару суток и заглянув в лог, увидите отпад кольцевых линков вместе с warm reboot. Для верности можно развернуть заббикс на виртуальной машине и сделать 3 копии, чтоб SNMP прям нещадно опрашивала железки с 3-х точек. Так же обратить внимание хочу, что все сообщения летят в syslog, кроме Warm reboot.. хотя в логе на коммутаторе есть и оповещение о таких сообщениях в сислог включено. Прошивка V5.8 build 21072216.

Ну это ни что иное как пример доведения ситуации до абсурда. Конечно, если вопрос бы стоял так, типа, а не добавите ли вы на CN2650 пару-тройку 10Гб портов + подержку mpls, тогда да - явный перебор А тут... мелочь, которая при чём и так работает в одну сторону. RIP вот есть... а вот такой казалось бы обычной вещи нет.

Могу ошибаться, пользуем turbo ring v2 на 4-ках коммутаторов, по-моему да, на мастере.

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

Вы аллегорию слишком контрастную привели. Речь не о переделке оборудования из самолёта в корабль, а о добавлении по сути стандартного функционала сетевого интерфейса. Вот пирмерно таким макаром, как вы и говорили, была добавлена ARP таблица в EDR-810 и, я позозреваю, функция трэкинга на IKS 6726 в одной из прошивок.