40Гбит/c по воздуху, уже можно. Точнее 4 по 10Гбит/c на расстояние в 11км. В статье не так много технических деталей, но есть история вопроса.
Лучше резерв на радиолинке чем никакого, тем более гигабиты/c можно получать достаточно легко в пределах нескольких километров. Хотя такой резерв доставляет больше мороки, особенно тем кто всё время с кабелем работает.

Проверщик на живость URL по списку из файла, говорят что быстрый.

MANRS собрали в одном месте статистику по проблемам и готовности участников интернет отвечать за свои сети, называется observatory.manrs.org. Соответствие данных IRR действительности, покрытие RPKI, фильтрация, спуфинг, количество инцидентов с маршрутизацией. Можно смотреть по странам и по RIR, есть история и сравнения. Наверное, когда все примут соглашения MANRS, то все графики будут зелёные, но пока не так. Почитать что к чему, большое спасибо за ссылку от нашего подписчика, можно на arstechnica.com.

Yandex молодцы - включили проверку по RPKI, скоро у всех. Может расскажут на Nexthop, в программе есть доклад про безопасность в BGP.

Первый наш национальный домен SU отмечает своё день рождение сегодня. RU - младший брат.

В блоге Cloudflare детальный технический разбор закрытия TCP сокетов по истечении времени - в каких случаях это происходит, а в каких не происходит. Разбираются ситуации вокруг использования опции TCP_USER_TIMEOUT и как она сочетается с другими механизмами и параметрами, в частности с TCP keepalive при различных состояниях соединения.
В конце, конкретные рекомендации что и где включать для тех кто уже может в socket(). В начале, хорошо расписан процесс установления соединения TCP. Для админов есть опции sysсtl. И бонусом утилита которая используется в статье выложена на Github.

С помощью 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 заметно уменьшится.