Японский провайдер SAKURA internet рассказывает, не вдаваясь в детали, про свою систему мониторинга. Речь больше про TimescaleDB, но есть и про то как они на лету, от 2000 до 4000 запросов в секунду, выдёргивают маршрутную информацию с GoBGP и рисуют красивые графики в Grafana.

Подписаны все используемые префиксы в Королевстве Бутан. Можно слать свои поздравления. Наверное, стоит сказать что границы в Интернет, пока, условности и там свои границы в виде автономных систем. В Бутане их совсем не много.

Если всё ещё подбираете DHCP сервер для IPv6, то посмотрите на dhcpy6d, который за 7 лет дорос до версии 1.0. Внутри Python 3, всё доступно на Github. За ссылку большое спасибо нашему подписчику.
Набор функций достаточен для многих задач, при этом есть поддержка внешних вызовов, если уж совсем не хочется менять исходный код. Мы для экспериментов в IPv6 использовали тоже реализацию на Python, но совсем простенькую, до такой степени что всё решалось переписыванием и дописыванием логики в самом исполняемом файле и сейчас я даже не нашёл первоисточник этого скрипта. Но работал он вполне исправно, для нескольких тысяч абонентов точно.

Мне подсказывают, что есть ещё популярная библиотека на Go, которая используется во многих реализациях DHCP, например, в Facebook. Для тех кто может и хочет делать, в том числе, и специфические вещи. Ссылки на примеры реализации и законченные продукты есть в readme.
Не забываем и про классику, так что выбор есть, помимо того, что можно и своё писать, или вообще принять что DHCPv6 не нужен.

Спецификация 800 Gigabit Ethernet

6 апреля 2020 года консорциум "25 Gigabit Ethernet", первоначально созданный для разработки спецификаций Ethernet 25, 50 и 100 Гбит / с, объявил, что изменил свое название на "Консорциум технологий Ethernet" - Ethernet Technology Consortium.
Это позволит "отразить новый акцент на более высокоскоростных технологиях Ethernet."

https://ethernettechnologyconsortium.org/press-room/press-releases/25-gigabit-ethernet-consortium-rebrands-to-ethernet-technology-consortium-announces-800-gigabit-ethernet-gbe-specification-152/

Одной из первых спецификаций, которую отстаивает Консорциум является спецификация 800GBASE-R для 800 Gigabit Ethernet (GbE).
Высокая скорость достигнута за счёт использования восьми линий со скоростью 106 Гбит/с.

Спецификация стандарта Ethernet 800G - https://ethernettechnologyconsortium.org/wp-content/uploads/2020/03/800G-Specification_r1.0.pdf

CLI vs API и всего остального, подборка ссылок из блога ipspace.com, сарказм как всегда на месте.
Для ленивых, вопрос не стоит или/или, нет никакой битвы, разные задачи - разные инструменты, при том что ни один из них не застыл на месте.

#ликбез #вещества 👉 Есть в законе «о Связи» такое понятие — «телематика». И эта «телематика» лицензируема. Зайдите на сайт своего провайдера — скорее всего, вы найдете в «подвале» сайта лицензию «телематических услуг связи». Её можно увидеть и у некоторых хостеров, но это отдельная история

☝️ Что иль кто есть «телематика»? Да никто не знает. Закон не описывает. Руководящий документ был мягко говоря странным. Но все серьёзно рассуждают и настаивают на своих версиях. Вдруг, в апреле 2020 года из сумрака выходит один из людей, который участвовал в попадании этой самой «телематики» в нормативную правовую базу РФ. Вот что ведает нам на страницах facebook Михаил Медриш

😱 «Ох, коллеги, читаю я все эти рассуждения про так называемые телематические услуги связи и понимаю, что уже почти никто не помнит, как они появились в нормативном поле, кто их продвигал и почему. У некоторых людей (и я помню этих людей) в головах была идея, что доступ в интернет это не услуга передачи данных, а что-то другое, а сама сеть интернет, как сеть связи, не является сетью передачи данных. А ещё в 2000 году появилось написанное год до того РД на телематику. Практически в то же время появилось ещё РД на передачу данных. Слово телематика было взято из рекомендаций ITU-T, где говорилось, что есть услуги связи телефонные, телеграфные, передачи данных и прочие, с общей вывеской телематические. К ним, например, относился Видеотекс, во Франции предоставлявшийся под торговой маркой Минитель. А соответствующие рекомендации написали люди из Франс Телекома. Так вот, в РД на телематику были описаны те самые прочие услуги. Я писал раздел «Услуги доступа к информационным ресурсам». Это была совершенно бредовая ситуация. Такой услуги, конечно, в реальной жизни не могло существовать. И правильнее всего было бы такую услугу в нормативном документе не упоминать, так как доступ к информационным ресурсам пользователь организует сам, обращаясь через сеть к сайту. Но проблема заключалась в том, что было выдано и действовало несколько сотен лицензий с такой формулировкой. Мы с Юрием Владимировичем Златкисом, который от Минсвязи руководил процессом, договорились, что я опишу услугу, как услугу оператора связи поставщику информационного сервиса (сейчас такие называются ОРИ), который, подключившись к сети, даёт возможность получать информацию из своего сервиса любому, кто её запросит через сеть. И тогда те, кто имеют такую лицензию, скорее всего, не будут её продлять, так как услуги передачи данных достаточно. После завершения действия всех этих дурацких лицензий новые выдаваться не будут. Но Златкис ушёл на пенсию ровно в 60, не успев довести РД до состояния утверждения Приказом. Дело заканчивал Александр Сергеевич Миков. Он прочитал текст, увидел странность, никого не спросил о причинах и внёс небольшие текстуальные изменения, которые полностью перевернули логику. В получателях услуги оказался конечный пользователь, имеющий доступ в Интернет. И РД был утверждён совсем не в таком виде, как мы со Златкисом планировали. Через некоторое время уже не при Микове, если я правильно помню, эта услуга со слегка видоизменившимся составом услуги стала называться телематической. И там остался тот самый дурацкий состав услуги для конечных пользователей - "доступа к информационным системам информационно-телекоммуникационных сетей, в том числе к сети Интернет". Мало того, ещё добавилась функция "приема и передачи телематических электронных сообщений". Понятно, что оператор связи ни то, ни другое не делает, так как он "труба", которая IP-пакеты в сеть и из сети передаёт. Но нет! Лицензии продолжают выдаваться и продлеваться. Все понимают по словом телематика, что хотят. Прямо беда! Друзья, ну перестаньте хотя бы вы употреблять это странное сочетание слов "телематическая услуга". За ними ведь ничего кроме ошибок, мифов и заблуждений не стоит. Вы лучше мойте руки, не болейте и развивайте наш замечательный интернет по мере сил :) Всем пламенный привет!»

😂 Каждый раз, натыкаясь на лицензию телеметических услуг связи, вспоминайте эти откровения

Аварий и простоев становится больше и больше именно в конфигурации и работе ПО, которое стало заметно сложнее, нежели в работе оборудования или инфраструктуре ДЦ.

У GitLab теперь есть IPv6, потому что он переехал на Cloudflare.

Chrome и, наверное, всё где используется Chromium, т.е. почти все браузеры, для определения что сначала надо зайти на captive portal использует случайно сгенерированные доменные имена. И по данным за 2018 год эти имена, похожие на те что генерирует Chrome, составляют преобладающую нагрузку в запросах на B-Root DNS.
Когда уже почти всё ушло на HTTPS, без помощи браузера captive portal вывести не удастся, перехватить и перенаправить трафик никак не получится не вызвав вопросы со стороны пользователя. А штука удобная, хорошо работает как напоминалка отключенным абонентам и экономит время ТП на звонках. Но, наверное, не такой ценой.
Firefox, кстати, использует предопределённую страничку HTTP, которую можно перехватывать провайдеру, по крайней мере использовал раньше, но возможно это не единственный его способ.
P.S. Кусок кода приводимый в статье находится в файле intranet_redirect_detector.cc.

Всё, уже и циска сдалась и собрала в одном месте гайды по настройке своего Cisco VPN SSL-IPSec Anyconnect на всём на свете. Ну или почти на всём...

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215331-anyconnect-implementation-and-performanc.html

5 препятствий которые предстоит преодолеть чтобы начать внедрять IPv6, а также подходы к их преодолению. Написано правдиво, но никак не успокаивающе, даже наоборот - это сложно, непонятно и дорого.
При том, это далеко не все проблемы, они даже не самые самые, это просто 5 проблем с которыми точно столкнутся все, а есть ещё 100500 с которыми столкнутся 99%, но про которые в статье не написано. Переход на IPv6 серьёзная и большая работа без мгновенного результата и техническая составляющая сетей тут далеко на самое важное.

DNS over что-то это всё ещё DNS и специально ни от каких атак специфических для DNS не защищает. Rebinding точно можно сделать.

На Habr впечатления от ACI и VXLAN внутри датацентров. Могу подтвердить, что многие шарахаются от графического интерфейса в силу привычки, но даже больше не от этого, а от потери иллюзии полного контроля. При том решения под ключ, вроде ACI, наверняка сэкономят средства в будущем, хотя бы за счёт того же графического интерфейса и управления в "один клик". Люди стоят дороже этого.

Делимся подробными post-mortem о произошедших на прошлой неделе инцидентах с DNS и о мерах, которые мы предпримем во избежание их повторения в будущем.

6 апреля:
Проблемы в работе DNS в зоне доступности ru-central1-c

7 апреля (инцидент повторился дважды):
Проблемы с резолвингом DNS - 13:41 - 14:32
Проблемы с резолвингом DNS - 21:03 - 21:29

Напоминаем, что мониторить статус работы сервисов всегда можно на нашем статус-борде.

​Что-то я пропустил, в OpenBSD есть looking glass для их же bgpd, что называется из коробки - bgplg. Выглядит симпатично и подкупающе просто (первая ссылка из Google). Настраивается тоже не сложно, на Хабр есть на русском.
Неплохой вариант для внутреннего потребления. У нас поднят немного допиленный от version6.net, когда-то очень популярный, сейчас его пожалуй не стоит использовать. И теперь я почти уверен на что его поменяю.

https://isbgpsafeyet.com/ проверь своего ISP.

В тервере есть очень известный парадокс дней рождений учеников в классе. Если учеников 23 или больше то вероятность, что дни рождения двух из них совпадут больше 50%.
А теперь представим что у нас есть несколько устройств одного производителя. Если MAC адреса для них сгенерированы случайно, это всего лишь 2^24, немногим меньше 17M вариантов адреса на устройство, так как старшая часть определяет производителя, то 1800 таких устройств дадут вероятность совпадения адресов хотя бы двух из них 9%. 5000 (на самом деле меньше) больше 50%.

Насколько такая ситуация реальна на практике? Вполне себе, самый простой пример из провайдерской жизни это телевизионные приставки (STB) которых много, они одного производителя и которые часто авторизуются в middleware по MAC адресам. Ещё часто они находятся в одном мультикаст вилане. Это не совсем широковещательный домен, но коллизии прямо на оборудовании возможны, при том что сравниваются не адреса, а их хеши которые могут иметь меньшую размерность.

Тот самый случай когда пригодились знания из почти школьной программы и, наконец, появился повод почувствовать себя инженером, задним числом. Не забывайте пользоваться математикой, она реально работает.

Радио-Т принёс на хвосте ssh-chat, игрушка для ностальгирующих в современной обёртке, пожалуй стоит поставить :)

Наверно, в этом посте в удобнейшем виде собраны все знания человечества про STP. Часть из них полезная, точно.
А всем правдорубам задание - найти чего там нет.
https://momcanfixanything.com/spanning-tree-protocol-summary/