Если что, то кашу и из топора сварить можно - сканер портов из подручных средств. Не универсальный, но рабочий.

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

​Коллеги развлекаются, привет им! Карта наша :) а иконы не наши - футболистов.
Если кто не узнал - это WhatsUp Gold 8, очень не новая система, но самая вменяемая для отрисовки карт, на мой взгляд конечно. Платная.
Почему-то ничего аналогичного: простого и удобного я не встречал. В следующей версии сильно добавили веса приложению, хотя и полезных вещей много привнесли. В любом случае, даже то что на картинке тянет несколько 1000 устройств ICMP мониторинга.

Много скриптов bash для повседневной работы. Не какие-то заморочки, такое накапливается довольно быстро если есть к этому повод.
Формат онлайнеров не очень комфортен, на мой взгляд - обычно такое пишется на лету и забрасывается. Если со скриптом продолжается работа, то он сам собой перерастает в более менее структурированный вид. Так что на любителя, острой необходимости в нём чаще всего нет.
Кстати, недаваний перевод про bash с habr - не забываем везде ставить кавычки.

Если OSPF хоть как-то для вас знаком, то в этой статье на cisco.com можно быстро въехать в IS-IS. Очень коротко про area, соседства, параметры с большим количеством отсылок к OSPF. На самом деле предыдущий опыт при изучении действительно нового часто мешает, скрывает детали и глубину, но позволяет взять быстрый старт.
Посмотреть более детально про IS-IS в видеоформате на русском можно у linkmeup (это последняя часть из 4-х, в ней есть ссылки не начало). Обычно я не очень перевариваю всякие видео, лучше картинки и текст, но посмотреть стоит.

Интересная статистика появилась в ежедневных отчётах bgp4_table и bgp6_table - количество ASn анонсирующих IPv4 и IPv6 префиксы соответственно (размер твита теперь позволяет):

There are 61326 unique originating ASNs. 46104 of these ASNs originate IPv4 only. 472 of these ASNs originate IPv6 only.

Настоящих интернет пользователей немногим больше 61000, тех кто умеет BGP. Почти у всех есть IPv4 префиксы в анонсах, при случае посмотрю кто таки смелые в количестве 472 штук чтобы не использовать IPv4. С учётом текущего размера IPv4 таблицы около 720000, получается в среднем каждая AS объявляет об 11 IPv4 префиксах.
IPv6 таблица сильно меньше: около 15000 AS и 53000 префиксов. Итого, 3 префикса на участника.

Чтобы постоянно не лазить в твиттер за этой статистикой я написал и поддерживаю работоспособность бота для телеграма - добро пожаловать в @bgp_table_bot. Может быть, когда нибудь, это будет прямая статистика с каких нибудь доступных коллекторов, а пока перепосты с твиттера.

Мне кажется невероятным, но что есть что есть. Полгода назад Kenneth Finnegan хотел разобраться как работает Интернет и с помощью друзей сделал себе настоящего провайдера на площадке HE.
Но на этом они не остановились и доросли до своего IX. Сейчас решают вопросы эффективного пиринга c root DNS, вплоть до того чтобы поддерживать один из узлов K-root на своих мощностях. Но дорого по железу, для хобби проекта-то! А ещё AS112, Akamai...

Мои восхищения усердием! Начало истории здесь, а в блоге автора подробности того как докатиться до такой жизни.

DHCPv6 совсем не то что DHCP для IPv4. Короткий рассказ о том, как прийти попить чайку к друзьям и починить нерешаемую проблему.
В заметке есть ещё очень важное замечание насчёт DHCPv6 vs SLAAC - предсказуемость это надёжность. Хоть DHCP и не самый предсказуемый протокол, но всё же лучше SLAAC в этом аспекте.

Так ли нужен BGP в датацентрах?. Если принять ограничение по росту до 100 коммутаторов по 48 портов, то получится что-то около 1500 мест куда можно подключить конечные устройства. Если хочется больше то сверху можно ещё архитектурой накрыть. Так что OSPF и IS-IS нормально потянут, но если хочется BGP, то можно и его - тут дело вкуса, как и во многих других случаях.
Только не стоит пренебрегать структурой, разделение на area, например. Засовывать всё в одно место, точно не самый лучший вариант.

Будет справедливо обозначить другую позицию по поводу предыдущего поста. Собственно Пепельняк уже участвует им в споре и по ссылкам можно найти начало.

Мне резонно замечают (чему я очень рад и благодарен за комментарии от наших подписчиков), что количество устройств не так важно, в целом, как топология. Для IGP количество связей более критично, а оно может нарастать лавинообразно. И тренды такие что BGP везде, например, даже в 2013 (большое выступление на YaC, в котором много времени уделяется протоколам). И это всё оправдано - маршрутизация спустилась до уровня хостов и спускается дальше к уровню приложений - а их очень много.

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

Попытка сделать жизнь проще путём развёртывания VPN сервисов в один клик. Много разных VPN + TOR. Поддерживаются облачные хостеры, кроме того можно ставить локально или на уже готовый сервер где угодно. Автоматизация - Ansible, Python 2.7.
Достаточно всё объёмно, для параноиков придётся вникать в результаты, что там поставилось. И проще от этого не станет ;)

ООН (ITU) за IPv6 решает оказывается, говорят IPv4 заканчиваются и вообще. Вот только подхода их к назначению адресов я тоже совершенно не понял, уж настолько перетёртая тема как переходить и как это лучше сделать, что уже многие механизмы перехода своё отжить успели. Но спишем не минусы бюрократии.

NAT пытается не ломать связность, но он делает гораздо больше чем просто подмена адресов в IP заголовках - гораздо больше. Собственно это как раз один из аргументов за IPv6 - устранение сущности с очень большими полномочиями (если не смотреть на плюсы).
Вот тут NAT правит DNS ответ, но это отключаемая функция и полезная наравне с другими алгоритмическими трансляциями, например PPTP, или FTP, или SIP. А вот RFC5508 - это лучшие практики для работы с ICMP и как бы не отключаемая:

If a NAT device receives an ICMP Error packet from an external realm, and the NAT device does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
a) Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and
b) Leave the ICMP Error type and code unchanged; and
c) Modify the destination IP address of the outer IP header to be the same as the source IP address of the embedded packet after translation.

То есть как ни старайся, но даже внутреннее поле данных ICMP в котором должен содержаться заголовок исходного пакета приведшего к ошибке (после NAT) пройдёт через трансляцию и адреса поправятся на приватные (как были до NAT). Такие дела.

Подборка графиков с IX с привязкой к времени матчей ЧМ2018. Как ни странно у нас такая же картина, хотя есть отдельный сервис ТВ который не завязан на Интернете. Но всё равно во время матчей видно что трафик с Интернета растёт. Причём это не доли процента, это десятки процентов. Интернет победил телевидение?

Минимализм некоторых *nix утилит сильно портит удобство использования. Например когда выполняется долгая операция без всякого вывода хода процесса. Причём реализация для разных платформ может быть разная, скажем для FreeBSD ftp выводит индикатор, а в Linux молчит как рыба об лёд. Для пакетного режима самое то, но не всегда *nix это только сервер.

Поправить ситуацию (отчасти) может вот этот набор утилит, которые читают состояние указателей файлов и выводят результат расчёта прошло/осталось. Подходит не для всего, но для многого, в случаях если надо пристально следить за процессом.

Что-то я прямо зачитался про DevOps, как-то органично совпало с моим мнением. Хотя к настоящим разработчикам я за всю жизнь ближе чем общение с БД админом, который в свою очередь общался с разработчиками нашей ERP никогда и не подходил и было это 10 лет назад. Выглядит конечно как: "Не читал, но осуждаю" - но если вдруг придётся столкнуться, обязательно мнение подкорректирую. Ну да ладно, зато DevOps'ы картинки красивые рисуют - про многое первый раз слышу.

BGP hijack настолько чувствительная штука, что различных систем и способов (мыслей) по предотвращению этого всё больше и больше. Вот ещё одна, которая пытается анализировать и обнаружить аномалии в анонсах, ссылка на скачивание в самом конце статьи. RPKI никто внедрять не хочет, однако все про него пишут :)
Данный инструментарий наверное и с утечками сможет помочь, хотя в статье тема не раскрыта. Но таких ситуаций не меньше - вот свежая между Cloudflare и Cogent.

Презентация Cisco с Nanog33 о том как чинить BGP, всего 191 слайд. Сильно меньше и в виде блок-схем есть на сайте Cisco.

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

Много картинок, много примеров. Формат презентации не самый удобный (если под рукой докладчика не иметь), но разжёвано качественно.

Если у вас дома OpenBSD или просто pf, а инет немного тормозит. Статья про конкретный случай и конкретную проблему bufferbloat, и конкретный инструмент FQ-CoDel для pf. К вопросу о том что QoS сам по себе не работает и почти всегда настройки по умолчанию, в каждом конкретном случае, приводят к проблемам. Их конечно можно не замечать или компенсировать полосой, что делают многие, но здесь это не сработало.
Помимо этого для себя отметил ещё один speedtest, который измерил скорость не сильно отличающуюся от моего тарифа, а также предоставил большое количество детализации, в частности про bufferbloat.

Обзор, достаточно подробный, 30 утилит для мониторинга в Linux и не только.
Собрали разношёрстную компанию вроде top, ps и ss вместе с netstat, iptraf, плюс tcpdump, плюс целые системы, например cacti и nagios. Есть примеры использования, для некоторых объясняются ключи вызова. Объёмная статья, но как минимум пробежаться по диагонали стоит.