В подтверждение предыдущего поста. Набор утилит для получения данных с каталистов, которые используют механизм трассировки на втором уровне для чего слушают 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.

Когда-то ребёнком читал в "Науке и Жизнь" про цифровое телевидение, если конечно я точно помню что это было именно про телевидение, а не просто про цифровые сигналы. Журнал был из середины или начала 80-х. Теперь другого телевидения у нас нет, только цифровое. По этому поводу передаю большой привет сотрудникам Волгоградского филиала РТРС, теперь не расслабляться и не уронить качество цифры до качества аналога :)

"Кричали женщины: ура! И в воздух чепчики бросали”.
Этого дня мы в редакции ждали долго. В России наконец-то завершился переход на цифровое вещание. В 21 регионе страны прошла четвертая волна отключения "аналога". Пилотный переход на "цифру" прошел в Твери в декабре прошлого года. Недавно Счетная палата рассказала во сколько обошлось подключение цифрового ТВ.
https://www.cableman.ru/content/v-rossii-zavershilsya-perekhod-na-tsifrovoe-veshchanie

Google рекламирует SRE, опять. Как всё хорошо и замечательно получилось у них в итоге и как они к этому пришли. Конечно, для этого уже есть свой awesome.

Russ White про то что технологии остаются технологиями и не надо боятся использовать что-то в локальной сети предприятия, думая что это не для этой сети, если этим используется какой нибудь большой провайдер услуг вроде Facebook.

С точки зрения интернет провайдера действует то же правило, особенно у нас, где очень многие взяли за основу своей сети в рамках города архитектуру локальной Ethernet сети предприятия чуть увеличив масштаб и у них получилось. Широко используя при этом DHCP security, 802.1x, port security, STP. А уж про способ подключения к Интернет через VPN и говорить нечего, сейчас их меньше но такие сети есть и работают. Даже у тех кто сидит на PPPoE в основе своей большая кампусная локальная сеть.

Я не говорю про всех, есть MPLS и его всё больше, потому что стало доступнее на оборудовании соответствующего ценового сегмента. Есть xDSL, вот про DOCSIS не знаю есть ли он где-то в России, но сейчас очень активно растёт PON, во многом являясь перепевкой DOCSIS для оптической сети. Это всё "чисто" телеком технологии, но их конечно никто не запрещает использовать. Всё дело в умении и выгоде. Поэтому заглядывайте иногда в соседнюю песочницу, там может оказаться что-то интересное.

Facebook скрестил машинное обучение и QUIC заменив там стандартный механизм реагирования на заторы. Будущее сетей, одно из возможных.