С помощью iperf можно генерировать и мультикаст трафик, собственно проверять его маршрутизацию, QoS. В статье и комментариях достаточно развёрнуто всё расписано. На сайте iperf то же, но покороче.

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

Самые-самые ошибки сетевой безопасности для устройств интернета вещей. На самом деле не только IoT и не только безопасности, и даже не только сетевой. Это то о чём все знают, но всё равно допускают такие оплошности. По многим причинам: лень, невнимательность, низкая квалификация, спешка, загруженность - в общем отговорок много, чтобы:

1. не ограничивать доступ
2. не обновляться
3. не знать какие устройства есть и как они функционируют
4. не обучать персонал и пользователей
5. использовать пароли по умолчанию

Так делать не надо, даже если это принтер.

PBR на ACI. По смыслу ничем не отличается от PBR на IOS или на чём угодно. Достаточно подробно написано, насколько может судить человек никогда не прикасавшийся к ACI. Интересно посмотреть на параллельный для меня мир, может, возможного будущего.

Очень обстоятельная статья на тему централизованности DNS. Сначала нагоняется много жути что централизованность плохо и это приводит к смерти такой системы (рынка) и даже приводятся графики что 90% пользователей используют не более 10% DNS резолверов, даже меньше 2%.
Но потом становится веселее, потому что исключается фактор, что пользователи большой сети дают больше процентов в статистику и проводятся уже более обнадёживающие показатели. Более половины пользователей используют серверы DNS внутри своей AS (своего интернет провайдера), а на долю публичных DNS приходится не более 30%. Живые графики можно смотреть на stats.labs.apnic.net.

Метод сбора данных - баннерная реклама, за что благодарят Google и это надо учитывать когда смотрите на статистику, как минимум потому что измеряется то что использует браузер, которых раз два и обчёлся, о чём в статье упомянуто. Есть и про DoH, возможно этот фактор в ближайшем будущем как раз и будет является тем что соберёт DNS в одну корзину.

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

DTP/LLDP/CDP/VTP, HSRP/VRRP, PIM, OSPF/EIGRP/RIP, Telnet/SSH/HTTP, SMI/ZTP - должны смотреть только туда куда нужно, быть выключены или заблокированы с помощью ACL. И это далеко не полный список, но при этом очень простой. А ещё не забываем про vlan hopping, например, что конечно посложнее, но не сильно. И конечно обновляемся, ошибки в ПО это обыденность.

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

В подтверждение предыдущего поста. Набор утилит для получения данных с каталистов, которые используют механизм трассировки на втором уровне для чего слушают UDP порт 2228. Я попробовал enumerate-vlans на Catalist 2950 (правда, совсем уже не новой) и всё отлично сработало:

C:\> enumerate-vlans.exe 192.0.2.2
Target info:
Hostname: c2950-F1C23
Platform: WS-C2950G-48-EI
Claimed IP: 192.0.2.2
Known IP Addresses:
192.0.2.2 responds from 192.0.2.2 8.053ms
Target address: 192.0.2.2
Listen address: 192.0.2.2
Local address: 203.0.113.2
4094 / 4094 [---------------------------] 100.00% 189 p/s

5 VLANs found: 11 15 91 313 516

При этом access-class на авторизацию не работает, то есть защищаться надо по другому. Доступно и из другой подсети, через маршрутизацию.

Компилируется go build. Подробности формата и примеры посложнее по этой ссылке.

Если на интерфейсе повесить несколько IP адресов, какой из них будет использоваться? В мире Juniper это сделано вот так:

Use preferred when the destination is on the same subnet.
Use primary when the destination is on a different subnet.
And remember that Lowest IP wins.

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

Вот это правда крутая фишка - использовать IP SLA для изменения политик route-map BGP.
IP SLA это высокоуровневый способ принимать решения, а чем выше уровень тем решения сложнее. И вероятность ошибки в этих решениях больше: если RTT повысился с 10 до 20мс это уже плохо и пора переключаться? а если до 30мс? Способ предотвратить последствия аварий которые сложно предотвратить другим путём, обоюдоострый, но так почти со всеми инструментами.

Хроники последних дней IPv4. У RIPE NCC кончились непрерывные блоки по /22, поэтому счастливчикам достанутся несколько префиксов по /23 или /24. Адреса всё ещё есть, примерно на 1000 новых LIR и скорее всего все места в этой очереди уже заняты.

У пользователей Juniper есть JSON, XML, SET-режим и это помимо структурированного текста конфигурации, но сейчас популярны YAML и TOML. За всем не угнаться и смысла в этом никакого нет, поэтому берём AWK и делаем то что нам надо.

awk и perl, bash, sed, grep типичные иструменты типичного пользователя *nix системы, даже не админа. Подобные скрипты пишутся за пару часов со справочником или за пару минут если пользуешься инструментом чаще чем раз в месяц. Мой коллега на прошлой неделе написал конвертер конфигурации коммутатора одного вендора, в конфигурацию коммутатора другого вендора и это в порядке вещей, никто не удивился, хотя он конечно молодец. Слишком много к этому внимания сегодня, системы стали через чур дружелюбными, поэтому многим приходится заново переоткрывать то что в них было всегда.

Вы знали что у HTTP есть собственный логотип? Мало того, он теперь изменился.

Старый и новый.

Пример поиска проблемы в маршрутизации мультикаст трафика, которая оказалась проблемой в реализации IGMP на конкретном устройстве и прошивке. Но когда начинаешь искать причину любого сбоя об это не знаешь. Были ли внешние причины, обрыв кабеля, например. Ошибся ли ты с конфигурацией, а такое бывает часто. Связано это с самим устройством в конкретный момент, например высокая загрузка CPU или портов. Или ошибка кроется в программном обеспечении. Миллион причин разной степени вероятности, которые надо исключать все, то что останется и будет решением. Как раз этот путь очень хорошо показан в статье.

Чем лучше знаешь как это работает, тем быстрее это происходит, потому что видишь что так не должно быть. Чем больше опыта и уверенности в этих знаниях, тем это происходит ещё быстрее, потому что очень часто ошибка именно в тебе и доверять себе тоже надо учиться.

Ещё одно следствие того что у RIPE NCC скоро кончатся IPv4 адреса - большое количество новых LIR, их можно открывать сколько хочешь, потому что это единственный способ получить новые адреса не покупая их на рынке. Через некоторое время адреса можно передать в нужный LIR и лишние закрыть, сэкономив на членских взносах, что скорее всего и произойдет в ближайшие пару лет, количество LIR заметно уменьшится.

cat очень простая утилита, поэтому не всегда безопасная. Если привести простой пример:

$ echo -n -e "Invisible line\rVisible line \n" > hidden.txt
$ cat hidden.txt
Visible line

Я периодически применяю специальные символы для формирования вывода на консоль, но вот cat меня почему-то удивил, хотя и логично было ожидать от него именно такого поведения. Может быть, потому что я не думал в таком ключе. Escape-последовательности тоже работают, что делает cat ещё острее.

Правдивое описание ситуации с автоматизацией сетей. Вопрос не столько в устройствах, хотя и это важная часть, и не в языках программирования и не в инструментах. Вопрос в связывании уже существующих систем между собой. И хорошо если они находятся в рамках одной административной единицы, часто перед этим придётся ещё поменять внутренние процессы между отделами или филиалами, а это уже политика.
Добавим сюда, то что сети построенные пусть 3 года назад, даже если и строились качественно, скорее всего уже содержат если и не костыли то исключения. А что говорить про сети которые развивались годами и прошли не одну стадию модернизаций. Дьявол всегда в мелочах, о чём в статье, пусть во многом обзорной, написано не плохо. Не забывайте заглядывать под спойлеры.

Про DNS TTL, немного статистики кто какие использует и несколько рекомендаций к применению. Если установить TTL побольше это позволит ближайшим к потребителю DNS кешам взять обработку запросов на себя, тем самым уменьшить время отклика и снизить нагрузку на авторитативные серверы. Если поменьше, добавит гибкости и скорости реакции в управлении доменами, это важно если использовать DNS как механизма обнаружения сервисов или для борьбы с DDoS и балансировки. Согласия какие TTL использовать, как следует из статьи, нет. И даже среди TLD встречаются значения меньшие 5 минут.

Оболочка для man pages с поиском и гиперссылками. Придётся собирать самим.
А чтобы не запутаться где хранить полученную программу - шпаргалка с описанием дерева каталогов Linux.

Полный инженерного сарказма пост про то как зарезервировать подключение к Интернет через одного провайдера. Ответ - подключить второго. Но Иван Пепельняк перечисляет и несколько других вариантов, более технических. В любом случае единственная точка отказа остаётся единственной точкой отказа, сколько бы устройств там не стояло.

Кстати, вариант с /29 в сторону апстрима очень удобен на практике и позволяет сделать несколько вещей. Помимо того чтобы поднять вторую BGP сессию на отдельном спикере, можно поставить устройство для мониторинга непосредственно в сети на границе двух операторов, хорошая поддержка при выяснении вопроса на чьей стороне проблема. Ещё можно поиграться с next-hop балансируя трафик на разные устройства в этом маленьком импровизированном IX. Наверное, для этого нужны хорошие отношения со своими провайдерами, у нас так получилось.

Замечательная статья про Traffic Engineering внутри AWS, в которой выясняется что путь внутри облака между регионами может меняться по нескольку раз за минуту со скачками RTT в десятки миллисекунд. Для этого использовались ресурсы в разных частях сети, устанавливались TCP сессии на разных портах и измерялись задержки. Величина этой задержки во многом зависит от использованных портов, при этом около 20% соединений будут менять эту задержку (путь) раз в 10 секунд. Что конечно сказывается на обработке трафика на конечных узлах, в частности происходит постоянная перестановка пакетов из-за того что между разными путями скорость доставки сильно разная. Что в свою очередь может служить сигналом TCP о заторах и уменьшению скорости передачи уже самим протоколом.

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

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

​Насколько хорошо вы знаете curl? Ben Cox написал игру "You can't curl under pressure". Нужно немного промотать вниз, сначала идёт описание идеи.
Всё очень просто - вопрос и ваш ответ в виде командной строки с curl, в то время как вверху тикает таймер. Хороший способ понять глубину своего незнания. Технические подробности реализации тоже присутствуют, код доступен на GitHub.