Если вы решаете свою проблему с помощью регулярных выражений, то у вас теперь две проблемы. Коллега поделился ссылкой mathiasbynens.be/demo/url-regex - разные регулярные выражения для проверки URL. Табличка со сравнением кто прав и кто не прав.
Автор сразу оговаривается, что даже технически правильные строки могут не валидироваться по его условиям, потому что это его условия и ему так надо. Но всё же IP адреса с 0 или 255 в последнем октете довольно часто встречаются и они правильные, это прямо типичная ошибка дилетанта. Да и не все частные диапазоны вырезаны.
Мораль, регулярные выражения это личное, за свои ошибки есть кого винить и их есть кому исправить, а вот за ошибки в строке скопированной из Интернета можно очень больно получить потом. Поэтому только сами и только то что нужно, тем более это совсем не сложно ;) и тесты, тесты, тесты с максимальным покрытием.

Интересное, чисто научное, исследование, в котором удалось добиться передачи со скоростью терабит в секунду по медной паре. На N+1 только обзор, саму работу можно читать на aip.scitation.org. В статье не раз упоминается знакомый нам DSL (на N+1 сделали непривычный перевод "цифровая абонентская линия"), но на самом деле там собрали волновод (это важно) совсем не похожий на обычную телефонную пару, хотя и говорят что это приблизительно она и есть. Дальше увеличили частоту до 200ГГц и измерили результат, который на 9 метрах составил более терабита в секунду, а на 15 метрах около 30 гигабит в секунду. Собственно, ещё упоминается что оптика имеет большую стоимость со ссылкой на статью из 2007, а значит перспективы у такого решения есть. Поживём увидим, тем и хороши научные работы: может быть и на настоящем DSL скоро доберутся хотя бы до гигабитных скоростей, но пока оптика рулит.

За локальные DC++, да, обидно, но тут копирайт сыграл бОльшую роль. Весь описываемый процесс, примерно, лет 15 занял, первые массовые безлимитные тарифы от 8кбит/с до 64кбит/с это где-то 2005-2007 год в завистмости от региона.

- «Ой, у нас каналы перегружены», в историческом порядке:

1. Основные генераторы интернет-трафика — Youtube/Netflix — проектируются с использованием клиент-серверной архитектуры доставки видео, и до сих пор используют только её.

2. Проводные провайдеры вводят дешевые безлимитные тарифы, пользователи перестают считать трафик.

3. Проводные провайдеры отказываются от бесплатных локальных ресурсов, DC++-хабов, BitTorrent retracker'ов, всё больше интернет-трафика.

4. Мобильные телефоны и коммуникаторы становятся смартфонами с малым объемом памяти, доступные цены на мобильный интернет.

5. Дешевые и быстрые безлимитные тарифы полностью вытесняют оплату по трафику у проводных провайдеров, пользователи перестают хранить медиафайлы: зачем, если можно скачать или слушать/смотреть во «ВКонтакте»?

6. ПО, ранее использовавшие p2p-архитектуру, переделывается под клиент-серверную (Skype), или становится нишевым (SIP).

7. Пиратские «онлайн-кинотеатры» завоёвывают популярность, торрент-трекеры теряют популярность.

8. Dropbox, Яндекс.Диск и компания: зачем хранить файлы на ПК и передавать между ПК/смартфоном в пределах домашней сети, если можно хранить в интернете?

9. Дешевые и быстрые безлимитные тарифы у мобильных операторов (но с ограничением p2p-сетей), производительные смартфоны с малым объемом памяти: зачем хранить музыку на смартфоне, если можно слушать со Spotify?

10. Интернет-цензура в России: часть сайтов перестаёт открываться по непонятным причинам, Always-on VPN в другую страну.

11. Массовое шифрование всего трафика в интернете, фактическая невозможность нормального/массового использования локальных кеширующих прокси-серверов.

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

13. Повальное шифрование трафика в интернете, превращение всего в клиент-серверную архитектуру, SSL Pinning в программах, DNS over HTTPS в браузерах.

Виден ли свет в конце шифрованного туннеля провайдерской трубы? За последние годы появилось, по меньшей мере, 2 серьёзных проекта: IPFS и ZeroNet. Первый функционально скуден, но поддерживается крупными игроками (CloudFlare) и сравнительно распространён, а второй — не в пример функционально продвинут, но не получает должного внимания. Также есть нишевые: PeerTube, DAT. Если не все они, то я не знаю, кто.

Забыл еще важную вещь: у абсолютно всех сервисов аудио- и видеовещания отсутствует функция скачивания файлов. Смотрите онлайн, слушайте онлайн.

https://twitter.com/ValdikSS/status/1246183074771107843

Очень подробно как дружить Ansible и Cisco IOS - готовые плейбуки и подробные комментарии к ним для разных аспектов настройки: маршрутизация, управление, все базовые и повседневные операции.
Следующая часть серии про JunOS и это ещё не конец.

Японский провайдер 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, наверняка сэкономят средства в будущем, хотя бы за счёт того же графического интерфейса и управления в "один клик". Люди стоят дороже этого.