Если основательно подходить к планированию и проектированию сети или работ на сети, то перед тем как что-то сделать надо это попробовать. В тестовом окружении, реальном или виртуальном, может быть даже на рабочем участке сети. Чем больше сеть и чем масштабнее проект тем это сделать сложнее, но и в этом случае можно смоделировать поведение в тех или иных условиях.

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

Но разве не в этом и заключается работа сетевого инженера? И такие инструменты, конечно, должны быть, об одном из которых в блоге APNIC - pyNTM, а также упоминаются несколько других коммерческих продуктов. Это не готовое приложение - библиотека/фреймворк в который придётся вникать, но который, возможно, выведет ваш подход к работе на новый уровень. В любом случае, обоснование к закупке где фигурирует строгий математический расчёт выглядит солиднее, хотя это может и не добавить ему шансов на реализацию.

Если у вас есть один машиночитаемый документ, то из него достаточно легко, гораздо легче чем не имея такой документ, можно сделать любой другой. Например, из файлов drawthe.net рабочую топологию для GNS3 с помощью пары страничек кода на Python. И уже не надо себя ограничивать нелюбимым редактором, комбинируй как хочешь, но чуть-чуть программировать надо уметь.

Книга по SDN, во всех его смыслах. Если не всё, то многое в одном месте разложенное по полочкам. Всё ещё в процессе написания, я думаю в постоянном процессе, объёмы небольшие чтобы за вечер осилить.

Хорошие инструменты подходят сетям любого размера: большой экран - Network Weathermap в Cacti, я так понимаю это магистральная сеть на всю страну. На мониторе справа вкладка активных триггеров Zabbix.

​Что такое шик - это когда даже в мелочах не к чему придраться. Забавный и вполне понятный своим происхождением глюк на одном из наших давно, очень давно, непрерывно работающих коммутаторов. Не хочется думать что производители не рассчитывали, что их оборудование будет так долго работать :) тем более работой мы вполне довольны, не восхищены, но и не огорчены.
Из таких мелочей, в основном, и складывается сложность: мелочи в протоколах, мелочи в их реализации, мелочи во взаимодействии с конкретным оборудованием и сотня других причин и мелочей.

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

Ещё даже не все настроили DoH на Микротике, а они уже RPKI выкатывают в бете.

​День запуска IPv6, прошло 8 лет. График Google перебрался за 30% и показывает сейчас линейный рост. Где-то на границе 2017-2018 случился перелом, до этого было похоже на параболу. Плюс 5% проникновения в год, до 100% осталось 14 лет, но это не точно.

BGPlay ко вчерашней аварии Telegram. С нашей стороны, да и не только, наблюдалось полная потеря анонсов из AS62041. Хорошо видны моменты, когда упало и когда поднялось.

Geoff Huston про будущее Интернета, будущее технологий. Это ответ на New IP, но совсем не про него. А про то, что вообще можно считать прорывными технологиями и какие из тех современных, что на слуху у всех, мы уже используем широко или только начинаем использовать, и почему они прорывные по его мнению. Бонусом, исторические аналогии, подглядывание в будущее и несколько едких замечаний в сторону бизнеса.

Наверное, все знают или хотя бы наслышаны о страшилках и опасности редистрибьюции BGP full view в OSPF. Статья о том, что конкретно при этом происходит с точки зрения протокола, примеры и рекомендации так не делать.

Случаи бывают разные и разные необходимости, просто следует относиться к этому очень внимательно и не только к этому. Кстати, iBGP в Cisco по умолчанию нельзя проанонсировать в OSPF, но тут, наверное, другой посыл.

Как бы не хотелось построить по настоящему отказоустойчивую и распределённую сеть, почти всегда останутся места более важные чем остальные. Это может быть оборудование, или магистраль, или целый ЦОД. Даже в глобальном масштабе случаются проколы.

Многие, если не большинство мелких и средних провайдеров, в том числе отдельные части у больших провайдеров не имеют горячего резерва 1+1. Хороший вариант если резерв потянет хотя бы 50% от общей нагрузки, чуть хуже, если то из чего можно собрать резерв есть в наличии, или это можно снять с другого менее загруженного участка сети. Частый вариант, нечем менять и тогда замена ищется у друзей или соседей, или собирается кардинально новая схема позволяющая работать хоть как-то.

Эту картину плохо видно в общем, но на вскидку за последние 4-5 лет, в нашем регионе я знаю про несколько подобных аварий, со сроками устранения до нескольких недель, то время чтобы найти и доставить адекватную замену или настроить неадекватную требующую переделку многих внутренних механизмов. И мы сейчас говорим про центральный узел, на периферию часто легче найти замену из ранее используемого оборудования, но уже выведенного из эксплуатации, или быстро купить ввиду меньших требований к функционалу и производительности, да и последствий меньше.

Ещё момент касающийся централизации и почему иметь две точки выхода в Интернет в разных частях, разнесённых географически, для многих совершенно не по силам - это СОРМ и уже многочисленные инициативы и законы по централизованному управлению трафиком, которые в принципе ломают децентрализацию, если в провайдере её имели хоть в каком-то виде.

Я хочу понимать почему так и даже сам иногда верю что это дорого и не оправдано, но это точно не правильно. Пусть у вас ничего не ломается, а если и ломается то всегда было что-то вместо.

​Всё что вы скажете или сделаете может быть использовано против вас. В блоге APNIC представление работы, в которой делается предположение о типе и модели устройства на основе срабатывающей защиты от ICMP флуда.

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

Метод может быть болезненным для роутеров, не зря же они защищаются, но на тех устройствах где тестировали всё было хорошо и ничего не упало.

Угадывать с какого IP будет получен ответ от устройства при использовании трассировки дело увлекательное, но неблагодарное, особенно в эпоху повсеместных туннелей. Однако кое-что можно предположить и даже выявить закономерности, что в случае использования L3VPN, роутер на границе туннеля ответит IP с исходящего интерфейса, а не входящего. Знать это важно для проведения всяких исследований настоящим учёным.

Обширная работа касающаяся этого "феномена" опубликована на CAIDA.org (pdf). Удивительно, что исследования требует созданная человеком конструкция и эта особенность находится не в результате чтения документации и общения с производителями, а в результате кропотливого и подробного анализа. Ссылка на готовый инструментарий на Github правда не рабочая, но как и подобает настоящей исследовательской работе написано всё подробно и дотошно с многочисленными экспериментами в реальных сетях.

Как управляться с dig - презентация c вебинара организованного ISC, запись тоже уже доступна.

У меня есть бумажная "Прикладная криптография" Брюса Шнайера, русское переиздание 2003 года. Я не знаю насколько это всё уже устарело, но встречаемая терминология, вроде, всё такая же. Вот другая "Прикладная криптография" из тех же лет, свободно доступная для скачивания. Но, собственно, и Шнайера сейчас можно легко найти на почитать не тратя ни копейки.

Сканеры портов TCP и UDP на полстранички кода в PowerShell. Можно сканировать по сетям или по списку, есть настройки таймаутов. На GitHub дополнительно лежит ещё парочка утилит для брутфорса паролей, тоже на PS.

В самом простейшем варианте можно использовать Test-NetConnection, чтобы определить доступность порта.

Проект по мониторингу некоторых публичных DNS резолверов на основе сети пробников smokeping и сами графики. К проекту можно присоединиться установив у себя ответчик. Что к чему и зачем автор это всё затеял подробно в статье, где он агитирует всех небольших интернет провайдеров установить локальный DNS резолвер для своих клиентов.

Обзорная статья про ECMP с прицелом на MPLS, но есть и про другое, включая некоторые типичные особенности и проблемы реализации в data plane.

NTP c TLS внутри - NTS, можно уже пробовать: если клиенты и серверы. Cкоро и в RFC. Путь который стоило пройти.