Задать вопрос
  • Возможно ли в UPDATE "видеть" результат обновления предыдущих строк?

    @Akina
    Alexeytur,
    Рекурсивное CTE поможет с этой проблемой?

    При использовании критерия сортировки, обеспечивающего уникальность - несомненно.
    Написано
  • RRPPP принципиально ли направление primary/secondary портов на транзитах?

    @Akina
    Mors Clamor, нет, это всё понятно... протокол уже есть, отказываться от него никто не позволит. По счастью, как я понимаю, у вас под рукой в принципе есть несколько единиц оборудования, которое держит этот протокол.

    Я просто к тому, что есть смысл собрать стенд на 5-6 коробок да на практике посмотреть, как это выглядит. Помацать в разных режимах и понять, что, как, куда и сколько.
    Написано
  • RRPPP принципиально ли направление primary/secondary портов на транзитах?

    @Akina
    Mors Clamor, пропадание мастера приводит к тому, что некому слать COMMON/COMPLETE-FLUSH-FDB. Как в этих условиях работает оставшаяся плеть, как передаются и обновляются ARP-таблицы, протокол в принципе не описывает. А это ведь достаточно критичный вопрос.
    Написано
  • RRPPP принципиально ли направление primary/secondary портов на транзитах?

    @Akina
    Mors Clamor,
    В том числе про failover выборы мастера я также слышу впервые, хотя перечитывал мануал как в оригинале так и в переводе.

    Я тоже не слышал. Но любой протокол устойчивости обязан предусматривать ЛЮБЫЕ типы аварии, и чётко определять, что "это мы лечим вот так, а вон то не лечим вообще".

    В данном конкретном случае протокол, скажем, вменяемо рассматривает все варианты пропадания линка (и вариант с дошедшим пакетом, и вариант с пакетом потерянным), а вот аварии с выходом из строя коммутатора не рассматривает ВООБЩЕ. То есть в случае фэйла транзита всё происходящее типа понятно и полностью соответствует случаю отвала отдельного линка. Но вариант, что вышел из строя именно мастер - по-моему, разработчики протокола просто взяли и посчитали такой вариант невозможным теоретически. Или наоборот, постыдились сказать, что такой вариант протокол не обрабатывает.

    PS. Я бы вообще отсоветовал бы использовать эти самоляпные проприетарные и мало с чем совместимые протоколы. У меня как раз был RRPP в магистральном кольце, и пришлось от него избавиться, заменив на пусть более медленный. но зато высокосовместимый ERPS. Кстати, это элементарно снизило набор резервного оборудования по стоимости аж втрое, и убрало головняк со временно-аварийными ремонтами, сильно упростив инструкцию.
    Написано
  • RRPPP принципиально ли направление primary/secondary портов на транзитах?

    @Akina
    Mors Clamor,
    Обрыв поделит кольцо на 2 ветки, в каждом транзит обнаружит обрыв и отправит через оставшийся интерфейс линкдаун

    Да. То есть КАЖДЫЙ коммутатор отправит ОДИН пакет. И да, чисто в теории тот, который пойдёт по более короткой ветке, придёт раньше - причём это совершенно не зависит от того, через какой порт пакет будет отправлен. На практике, с учётом загруженности каналов, всяко может статься. Главное, что дойдёт. Иначе и правда для перестроения топологии придётся ждать детектирования через недошедший Hello.

    2. То есть всё же есть разница в направлении первичного и вторичного портов для быстрого перестроения топологии? Вэтом и заключается мой вопрос

    До тех пор, пока мастер исправен - никакой разницы.

    А если фэйлится именно мастер (причём не линк падает, а сам коммутатор отлетает), то остальные просто обязаны в порядке failover выбрать временно себе нового мастера (а если нет - то протокол говно). И вот тут уже роли портов могут влиять, хотя не могу предсказать точно, как именно. Но вменяемого описания именно такого фэйла мне не попадалось. А предполагать можно вообще что угодно - вплоть до какой-нибудь дури, что они перейдут на STP.
    Написано
  • Возможно ли в UPDATE "видеть" результат обновления предыдущих строк?

    @Akina
    Но обычный UPDATE при обновлении нескольких строк не дает определенного порядка выполнения.

    Ну сделайте же нормально. В рекурсивном CTE (он гарантирует порядок обработки) получите данные для обновления (PrimaryID, New_PDRating) и по полученным значениям обновите вторую копию таблицы.

    А ещё - я не вижу инициализации "предыдущего" обновлённого значения для первой записи набора, которая не имеет предыдущей записи.
    Написано
  • RRPPP принципиально ли направление primary/secondary портов на транзитах?

    @Akina
    Mors Clamor,
    просто если это делает ЛЮБОЙ транзит, значит при обрыве будет сгенерировано 2 сообщения по разные от обрыва стороны.

    Чёблин? У транзита ДВА интерфейса в домене. Один упал. Рабочий остался ОДИН. Ну как может быть ДВА сообщения, а?

    claude мне озвучил принцип "транизт должен смотреть первичным портом в сторону мастера по кратчайшему пути", видимо, как раз в соответствии с доками Н3С. Таким образом, можно сделать вывод что в каждом полукольце первичные порты будут направлены в свою сторону, а соединение secondary-secondary будет на ровно противоположной мастеру стороне.

    Бред. Кольцо в RRPP - направленное. При правильной настройке в любой паре соседних коммутаторов кольца primary одного подключается к secondary соседнего. А если направление первичного и вторичного колец различаются, приоритет за первичным.

    мне нужна высокая доступность, чтобы linkdown пришел корректно, а не ждать 30 сек fail timer

    ??? Какой у вас диаметр кольца? средняя задержка управляющего пакета - 1 мс на линк, рекомендуемый диаметр кольца - емнип не более 12 коммутаторов, именно эти значения и определяют время восстановления связности в 50 мс.
    Написано
  • RRPPP принципиально ли направление primary/secondary портов на транзитах?

    @Akina
    Не могли бы вы немного объяснить логику пересылки health транизтами - они видят, в какой порт он пришел и пересылают в противоположный?

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

    Также, в доках h3c написано, что linkdown сообщение шлет только тот транзит, чей ВТОРИЧНЫЙ порт упал.

    link-down пакет высылается сразу после детекта падения ЛЮБОГО из интерфейсов домена, ессно через второй интерфейс домена.

    https://support.huawei.com/enterprise/en/doc/EDOC1...
    Transit nodes, edge nodes, or assistant edge nodes send LINK-DOWN packets to notify the master node that an interface is Down.


    Ни полслова про роль порта тут нет.

    Может, вы читаете частную реализацию на каком-то определённом оборудовании?
    Написано
  • Как пофиксить доступ по smb между двумя филиалами?

    @Akina
    Крупные провайдеры блокируют порты со 135 по 139, и 445 в целях безопасности своих абонентов.

    Это при том, что в соответствии с законом о предоставлении телематических услуг они емнип не имеют права на такое действие, в общем-то...
    Написано
  • Какой Excel установить на смену 2007?

    @Akina
    Dwellss,
    У меня 3 колонки, данные в ячейках неуникальны, и неуникальные данные подсвечиваются. Собственно, это единственная задача софтины.
    Извиняюсь, а нахрена она это делает?

    Ну и почитайте вот это: https://xyproblem.info/
    Написано
  • Какой Excel установить на смену 2007?

    @Akina
    80к строк - не такая уж и большая таблица. Хотя всё зависит от реального объёма данных, количества формул/стилей/форматов и пр.

    Но в любом случае Excel - табличный процессор, а не СУБД. То есть, вы его используете не по назначению. И тормоза - это логичное следствие вашей ошибки.

    Полностью согласен с тем, что говорит Adamos - надо менять инструмент.
    Написано
  • Как запустить mysql после ошибки?

    @Akina
    Вы сейчас в том состоянии, когда производится установка MySQL из ZIP - системные базы в наличии, но невалидны. Их просто нужно пересоздать в соответствии с методикой установки сервера. Хотя снести MySQL и поставить заново будет быстрее имхо... и уж точно проще.

    А вообще начать бы вам с проверки файловой системы.
    Написано
  • Что определяет выбор адреса сайта из всех, возвращённых DNS-сервером?

    @Akina Автор вопроса
    Amos_Kein, возможность выбрать меня экспертом не накладывает на меня никаких обязательств. И то, что я там не отметился, однозначно говорит, что ничего существенного по вопросу в дополнение к уже сказанному у меня нет.
    Написано
  • Что определяет выбор адреса сайта из всех, возвращённых DNS-сервером?

    @Akina Автор вопроса
    Amos_Kein, ну если он напрямую связан с моим вопросом, то почему нет?
    Написано
  • Что определяет выбор адреса сайта из всех, возвращённых DNS-сервером?

    @Akina Автор вопроса
    Эххх. Хотел поснифить обмены, посмотреть разницу. Но вчера последние 2 компа с проблемой вдруг "исправились". Уж не знаю, есть связь или нет, но они оба вчера ребутались из-за установки обновлений (KB5062554, KB5063326).
    Написано
  • Что определяет выбор адреса сайта из всех, возвращённых DNS-сервером?

    @Akina Автор вопроса
    aleks-th,
    Про кэш тоже не нужно забывать

    Обращаемся к сайту - not found.
    Пишем правильное соответствие в HOSTS - есть доступ.
    Убираем соответствие - снова not found.
    Кэш явно не при чём.
    Написано
  • Что определяет выбор адреса сайта из всех, возвращённых DNS-сервером?

    @Akina Автор вопроса
    Ziptar, там объяснено, что Round Robin организует изменение порядка передачи адресов, а клиент использует первый по списку.

    Однако это совершенно не объясняет СТАБИЛЬНОСТИ происходящего. Почему одна станция ВСЕГДА сразу получает доступ (читай - правильный адрес в начале списка), а другая, наоборот, не получает его НИКОГДА (пока не пропишешь правильный адрес явно в HOSTS). Я не верю, что DNS-серверы запоминают, кому в каком порядке что отдают, и помнят это неделями. Так же как и не верю что несколько не связанных между собой DNS-серверов (public серверы google, cloudflare, yandex, quad9 и пр.) умудряются отдавать эти адреса на определённую станцию в одном и том же порядке.

    Valentin Barbolin, в этом случае все станции получали бы доступ. Просто те, кому не повезло получить правильный адрес не первым, открывали бы сайт с задержкой. Но это не так - половина станций просто не получают доступ, т.е. даже не пытаются постучаться по второму адресу, когда первый неправильный и, соответственно, недоступен.

    Евгений, целевой домен присутствует только на одном из двух адресов. Почему CloudFlare отдаёт неправильный адрес в пакете информации, я понятия не имею... конечно, это неправильно. Но меня интересуют именно причины стабильности того, что часть станций справляется с проблемой, а другая нет.
    Написано
  • Как правильно организовать сеть на даче?

    @Akina
    Кабель между домами тянуть нет желания

    Господи, вот не поленись и проложи полевиком П296-м. У тебя там не километр, 100 мегабит в полном дуплексе по нему бегает вообще как по родному.
    Написано
  • От чего зависит время пинга?

    @Akina
    если у порта пропускная способность 100мбит/с, а провайдер ограничил скорость моей сети до 50мбит/с

    ... то половину времени порт передаёт и принимает, а вторую находится в режиме паузы и ничего не делает.
    Написано