Есть два работающих варианта — burstcoin и storj.
Первый больше похож на майнинг. Работает по принципу proof-of-capacity или proof-of-storage. Жесткий диск заполняется какими-то данными (это долго, примерно сутки на терабайт), затем происходит что-то вроде постоянного розыгрыша на основе этих данных примерно каждые десять минут, победитель получает приз за новый блок. Получается где-то 100 burstcoin в месяц на занятый терабайт. По текущему курсу это примерно 300 рублей.
STORJ — сдача пространства диска в аренду, доход начисляется в зависимости от места и трафика в своей валюте под названием STORJ. Не пробовал, но говорят что не везде хорошо идёт. И диск может долго заполняться.
Обещали выход ещё криптовалют chia и filecoin, но работающих вариантов пока не видел.
Можно майнить что-нибудь альтернативное, например gridcoin (по своему опыту), когда наберётся около сотни гридкоинов, это где-то месяца через три, в зависимости от мощности железа и обменного курса — можно обменять их на 0.001 (тысячную) биткоина. Тысячная это ориентировочный минимум на обменниках. Ну а когда на обменниках появится этот форк, если именно он вас интересует, можно будет обменять и на него тоже. Или можно с этой тысячной на своём счету попасть под форк, и получить несколько валют сразу.
А если есть хотя бы пол-терабайта лишнего места на диске, то есть ещё майнинг на жёстком диске, но это уже другая история.
Не одно и то же, на coinhive есть порог вывода, для coinhive он 0.05 XMR, для этого надо посчитать примерно 500 млн хэшей со скоростью 10-20 хэшей в секунду. Минимальная сумма для вывода накопится за 280-580 дней.
Опрос происходит где-то за час. Могло бы быть и быстрее, но пока это не критично.
Да, в базе хранится информация за несколько дней для обработки (чтобы аварии в отдельных сегментах не приводили с исчезновению части схемы), а также история для поиска.
Около 2 млн записей о мак-адресах, примерно 100 тыс записей ARP.
Так исторически сложилось, я работаю с тем, что есть.
Если интересно моё личное мнение, то UPS может управляться по SNMP, не вижу смысла изолировать одно оборудование с SNMP от другого.
Это заблуждение, они заполняются не от этого
Таблицы коммутации заполняются на транзитных свитчах от прохождения пакетов от пингуемого оборудования до роутера. Пинг как пакет в этом плане подходит.
У вас влан управления один на всю сеть, включая сервер, с которого пингуете?
Нет, у каждого роутера свой. Роутеры в разных районах города. Компьютер, с которого производится этот массовый пинг находится в отдельном L2 сегменте для мониторинга.
Снимите со свитча2 айпишник, отключите лишние протоколы, оставьте голую коммутацию, и тогда свит1 и свитч3 не будут ничего знать про свитч2, будут думать, что подключены напрямую, хотя трафик между ними будет ходить через свитч2. В каких-то случаях и айпишник снимать не придется, от ситуации зависит, от аклов, маршрутизации.
Да, этим способом нельзя обнаружить неуправляемое оборудование или оборудование, с которого нельзя получить таблицы коммутации.
Почему? На каком-нибудь узле Х этот влан может идти на 5 портов, вот и получается дерево.
Дерево получается для влана в целом, всё верно. Но это не поможет определить что куда (в каком порядке) включено.
Влан без мак-адресов не информативен.
Имея мак-адрес конкретного устройства (назовём устройство Х) и мак-адрес шлюза (где терминируется сеть этого Х) мы можем определить группу устройств (какое-то подмножество от дерева) где мак устройства Х и мак шлюза на разных портах. Это транзитные коммутаторы для этого Х. В дереве они следуют друг за другом, нужно только определить их порядок.
Тогда это уже получается не цепочка, а просто список устройств. Цепочка не сортируется.
Упорядоченный список, это важно для метода. Потому что потом мы проверяем на соответствие критерию a>b>c>d
Под клиентом имелось в виду любое устройство без таблиц коммутации, в данном способе нет никакой разницы, клиент или UPS, например.
с какой целью?
Чтобы таблицы коммутации устройств были заполнены. Ну и чтобы не ломиться на отключенные устройства.
Этот пункт вообще не понял. Даже фразу не понял. Что значит определить конечное устройство для мака?
MAC-адрес клиента светится (присутствует в таблицах коммутации) на всех коммутаторах между роутером и клиентом, конечное устройство это то, в которое включен пользователь.
— Эта цепочка может не содержать существующий транзитный свитч, через который идет цепочка.
Почему не может? Может и содержит:
Роутер — свитч1 — свитч2 — свитч3 — клиент
Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
— Это может быть не цепочка, а дерево
Для одной пары мак-влан — цепочка, ветвления ещё нет.
что означает процесс сортировки цепочки?
Каждому коммутатору присваивается вес на основании числа маков в параллельных вланах.
Например для мака 00-01-02-03-04-00 во влане 5 нашлись следующие коммутаторы:
192.168.0.17, 192.168.0.15, 192.168.0.22, 192.168.0.19, 192.168.0.18
Считаем число маков в параллельно идущих вланах:
192.168.0.17 (15 маков), 192.168.0.15 (22 мака), 192.168.0.22 (3 мака), 192.168.0.19 (84 мака), 192.168.0.18 (12 маков)
После сортировки:
192.168.0.19 (84 мака), 192.168.0.15 (22 мака), 192.168.0.17 (15 маков), 192.168.0.18 (12 маков), 192.168.0.22 (3 мака)
Получаем наиболее вероятный порядок включения оборудования:
192.168.0.19 -> 192.168.0.15 -> 192.168.0.17 -> 192.168.0.18 -> 192.168.0.22
Повторив достаточно большое количество раз операцию для разных мак-адресов (и отсортировав по тому, как часто встретилась та или иная связь) мы получим что-то такое:
Занимаюсь такой же проблемой для сети с примерно десятью тысячами устройств: cisco, d-link, huawei, extreme. С разными вланами для клиентов и управления и разными глюками оборудования.
Несколько уточнений и ограничений моего способа:
1) В каждом влане предполагается наличие только одного роутера. В нашей сети не всегда так, эти вланы не подходят для определения топологии и не учитываются.
2) Под оборудованием будет пониматься устройство, обладающее собственной таблицей коммутации. Под клиентом все остальные (это могут быть как клиенты, так и более «глупое» оборудование).
3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
4) Параллельные вланы — вланы, которые на всех свитчах выборки обладают одинаковым аплинком (портом в сторону роутера). Порт в сторону роутера определяется по началичию единственного порта с маком шлюза, мак шлюза определяется по IP-адресам роутеров и таблицам арпов.
5) Физическая топология может иметь кольца, логическая нет.
6) Есть устройства, которые не показывают некоторые мак-адреса (привет, des-3028), иногда даже адрес шлюза.
Схема в основном строится по таблицам коммутации (AFT в вашей терминологии, FDB в моей) в несколько этапов:
1) Делается пинг до всех устройств, обладающих собственной таблицей коммутации.
2) Со всех устройств собираются таблицы коммутации, с роутеров собираются ARP.
3) По этой информации определяется порты клиентов. Эти порты не содержат маков оборудования во влане управления (тут был глюк у многих коммутаторов, рассылающих свой мак в каких-нибудь ещё вланах помимо своего влана управления) и не являются транзитными (эта часть полуавтоматическая, система показывает и предлагает отметить вручную такие порты и мак-адреса, которые видны одновременно на нескольких портах, на которых нет мак-адресов оборудования. Я не нашёл способа это автоматизировать).
4) Для каждого мака определяется его конечное устройство из следующих соображений: для мака оборудования (устройства, обладающего собственной таблицей коммутации) это будет устройство с наименьшим числом маков в параллельных вланах, для мака клиента это порт из пункта 3.
На этом первый этап завершён, установлены соединения сети и соединения к клиентам, но не дополнительные, альтернативные или другие параллельные связи.
Второй этап:
1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
2) Каждая цепочка сортируется по числу маков в параллельных вланах.
3) Если нашлись такие четыре коммутатора что число маков (обозначим как a, b, c, d) на них соответствует правилу a>b>c>d, то считаем обнаруженной связь между b и с. Плюс ещё два варианта: a>b>c когда a наибольшее, тогда есть связь между a и b, и b>c>d когда d наименьшее, тогда есть связь между c и d.
4) Для каждой связи подсчитывается число попаданий, связи заносятся в схему начиная со связи с наибольшим весом, конфликтующие связи не учитываются (считаем их ошибками обнаружения).
Этот способ помогает найти все остальные связи, хотя ошибки тоже бывают. Как правило вызваны неодновременностью опроса устройств в сети (когда мак-адрес успел исчезнуть на части оборудования).
Смотря что хочется увидеть: картинку, или объёмную картинку.
Картинку можно увидеть без проблем. Проблема в том, что в кино на экран проецируются два изображения с разной поляризацией: одно для правого глаза, другое для левого. Поляризационные очки разделяют эти два изображения, оставляя для правого глаза только правое, а для левого только левое. В результате изображение кажется нам объёмным.
Обычный монитор не может выдать изображение такого вида. Он выдаёт обычное изображение без поляризации. Даже через поляризационные очки никакого разделения изображение на правое и левое не произойдёт. Картинка будет, объёма не будет.
На обычном мониторе можно посмотреть картинку через красно-синие очки, это да. А в кино уже используются специальные поляризационные очки, с ними на обычных мониторах не будет никакой трёхмерности.
Их можно из кинотеатра унести, оштрафуют всего на 2500 рублей.
Первый больше похож на майнинг. Работает по принципу proof-of-capacity или proof-of-storage. Жесткий диск заполняется какими-то данными (это долго, примерно сутки на терабайт), затем происходит что-то вроде постоянного розыгрыша на основе этих данных примерно каждые десять минут, победитель получает приз за новый блок. Получается где-то 100 burstcoin в месяц на занятый терабайт. По текущему курсу это примерно 300 рублей.
STORJ — сдача пространства диска в аренду, доход начисляется в зависимости от места и трафика в своей валюте под названием STORJ. Не пробовал, но говорят что не везде хорошо идёт. И диск может долго заполняться.
Обещали выход ещё криптовалют chia и filecoin, но работающих вариантов пока не видел.
А если есть хотя бы пол-терабайта лишнего места на диске, то есть ещё майнинг на жёстком диске, но это уже другая история.
Да, в базе хранится информация за несколько дней для обработки (чтобы аварии в отдельных сегментах не приводили с исчезновению части схемы), а также история для поиска.
Около 2 млн записей о мак-адресах, примерно 100 тыс записей ARP.
Так исторически сложилось, я работаю с тем, что есть.
Если интересно моё личное мнение, то UPS может управляться по SNMP, не вижу смысла изолировать одно оборудование с SNMP от другого.
Таблицы коммутации заполняются на транзитных свитчах от прохождения пакетов от пингуемого оборудования до роутера. Пинг как пакет в этом плане подходит.
Нет, у каждого роутера свой. Роутеры в разных районах города. Компьютер, с которого производится этот массовый пинг находится в отдельном L2 сегменте для мониторинга.
Да, этим способом нельзя обнаружить неуправляемое оборудование или оборудование, с которого нельзя получить таблицы коммутации.
Дерево получается для влана в целом, всё верно. Но это не поможет определить что куда (в каком порядке) включено.
Влан без мак-адресов не информативен.
Имея мак-адрес конкретного устройства (назовём устройство Х) и мак-адрес шлюза (где терминируется сеть этого Х) мы можем определить группу устройств (какое-то подмножество от дерева) где мак устройства Х и мак шлюза на разных портах. Это транзитные коммутаторы для этого Х. В дереве они следуют друг за другом, нужно только определить их порядок.
Упорядоченный список, это важно для метода. Потому что потом мы проверяем на соответствие критерию a>b>c>d
Под клиентом имелось в виду любое устройство без таблиц коммутации, в данном способе нет никакой разницы, клиент или UPS, например.
Чтобы таблицы коммутации устройств были заполнены. Ну и чтобы не ломиться на отключенные устройства.
MAC-адрес клиента светится (присутствует в таблицах коммутации) на всех коммутаторах между роутером и клиентом, конечное устройство это то, в которое включен пользователь.
Почему не может? Может и содержит:
Роутер — свитч1 — свитч2 — свитч3 — клиент
Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
Для одной пары мак-влан — цепочка, ветвления ещё нет.
Каждому коммутатору присваивается вес на основании числа маков в параллельных вланах.
Например для мака 00-01-02-03-04-00 во влане 5 нашлись следующие коммутаторы:
192.168.0.17, 192.168.0.15, 192.168.0.22, 192.168.0.19, 192.168.0.18
Считаем число маков в параллельно идущих вланах:
192.168.0.17 (15 маков), 192.168.0.15 (22 мака), 192.168.0.22 (3 мака), 192.168.0.19 (84 мака), 192.168.0.18 (12 маков)
После сортировки:
192.168.0.19 (84 мака), 192.168.0.15 (22 мака), 192.168.0.17 (15 маков), 192.168.0.18 (12 маков), 192.168.0.22 (3 мака)
Получаем наиболее вероятный порядок включения оборудования:
192.168.0.19 -> 192.168.0.15 -> 192.168.0.17 -> 192.168.0.18 -> 192.168.0.22
Заносим в таблицу пары связей:
192.168.0.19 -> 192.168.0.15 (1 раз)
192.168.0.15 -> 192.168.0.17 (1 раз)
192.168.0.17 -> 192.168.0.18 (1 раз)
192.168.0.18 -> 192.168.0.22 (1 раз)
Повторив достаточно большое количество раз операцию для разных мак-адресов (и отсортировав по тому, как часто встретилась та или иная связь) мы получим что-то такое:
192.168.0.19 -> 192.168.0.15 (300 раз)
192.168.0.15 -> 192.168.0.17 (50 раз)
192.168.0.17 -> 192.168.0.18 (26 раз)
192.168.0.18 -> 192.168.0.22 (10 раз)
И какое-нибудь ошибочное, которое будет отброшено
192.168.0.17 -> 192.168.0.22 (1 раз)
Несколько уточнений и ограничений моего способа:
1) В каждом влане предполагается наличие только одного роутера. В нашей сети не всегда так, эти вланы не подходят для определения топологии и не учитываются.
2) Под оборудованием будет пониматься устройство, обладающее собственной таблицей коммутации. Под клиентом все остальные (это могут быть как клиенты, так и более «глупое» оборудование).
3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
4) Параллельные вланы — вланы, которые на всех свитчах выборки обладают одинаковым аплинком (портом в сторону роутера). Порт в сторону роутера определяется по началичию единственного порта с маком шлюза, мак шлюза определяется по IP-адресам роутеров и таблицам арпов.
5) Физическая топология может иметь кольца, логическая нет.
6) Есть устройства, которые не показывают некоторые мак-адреса (привет, des-3028), иногда даже адрес шлюза.
Схема в основном строится по таблицам коммутации (AFT в вашей терминологии, FDB в моей) в несколько этапов:
1) Делается пинг до всех устройств, обладающих собственной таблицей коммутации.
2) Со всех устройств собираются таблицы коммутации, с роутеров собираются ARP.
3) По этой информации определяется порты клиентов. Эти порты не содержат маков оборудования во влане управления (тут был глюк у многих коммутаторов, рассылающих свой мак в каких-нибудь ещё вланах помимо своего влана управления) и не являются транзитными (эта часть полуавтоматическая, система показывает и предлагает отметить вручную такие порты и мак-адреса, которые видны одновременно на нескольких портах, на которых нет мак-адресов оборудования. Я не нашёл способа это автоматизировать).
4) Для каждого мака определяется его конечное устройство из следующих соображений: для мака оборудования (устройства, обладающего собственной таблицей коммутации) это будет устройство с наименьшим числом маков в параллельных вланах, для мака клиента это порт из пункта 3.
На этом первый этап завершён, установлены соединения сети и соединения к клиентам, но не дополнительные, альтернативные или другие параллельные связи.
Второй этап:
1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
2) Каждая цепочка сортируется по числу маков в параллельных вланах.
3) Если нашлись такие четыре коммутатора что число маков (обозначим как a, b, c, d) на них соответствует правилу a>b>c>d, то считаем обнаруженной связь между b и с. Плюс ещё два варианта: a>b>c когда a наибольшее, тогда есть связь между a и b, и b>c>d когда d наименьшее, тогда есть связь между c и d.
4) Для каждой связи подсчитывается число попаданий, связи заносятся в схему начиная со связи с наибольшим весом, конфликтующие связи не учитываются (считаем их ошибками обнаружения).
Этот способ помогает найти все остальные связи, хотя ошибки тоже бывают. Как правило вызваны неодновременностью опроса устройств в сети (когда мак-адрес успел исчезнуть на части оборудования).
www.racurs.ru/www_download/articles/overview_stereomonitors.pdf
Картинку можно увидеть без проблем. Проблема в том, что в кино на экран проецируются два изображения с разной поляризацией: одно для правого глаза, другое для левого. Поляризационные очки разделяют эти два изображения, оставляя для правого глаза только правое, а для левого только левое. В результате изображение кажется нам объёмным.
Обычный монитор не может выдать изображение такого вида. Он выдаёт обычное изображение без поляризации. Даже через поляризационные очки никакого разделения изображение на правое и левое не произойдёт. Картинка будет, объёма не будет.
Их можно из кинотеатра унести, оштрафуют всего на 2500 рублей.
нулей = 99959,
единиц = 99758,
двоек = 100026,
троек = 100229,
четвёрок = 100230,
пятёрок = 100359,
шестёрок = 99548,
семёрок = 99800,
восьмёрок = 99985,
девяток = 100106.
Так как солнце делали не мы, его энергия для нас даровая.