​RFC это всего лишь RFC и даже MUST нам не указ. Работа в которой исследуется соответствие стандарта TCP (RFC793) обязательным требованиям и в итоге, проблемы есть как на уровне операционных систем и их стека, так и в большом Интернете.
При этом оно работает и можно сказать что успешно уже много-много лет. Может быть это говорит насколько силён запас прочности заложенный в RFC, или насколько все привыкли что RFC не соблюдаются и поэтому реализуют их с максимальным уровнем толерантности даже к обязательным требованиям.

Про микротики и VXLAN, наверное, уже все слышали. Вот минимальная лаба в виртуальном окружении со всеми нужными настройками.

Почему Ethernet MTU 1500 байт? А всё очень просто, дело в деньгах, точнее в памяти для буфера сетевой карты - 500 байт на заголовки и килобайт на данные:

The quote is correct; the primary reason for the 1500 byte frame length limit was to reduce the buffer memory requirement for network interfaces.
The intent was to allow for 1K byte of data, plus 500 bytes for protocoloverhead, encapsulation, etc. There *was* a single, deciding moment during the DEC-Xerox discussions when we locked down the length. In retrospect, a longer maximum might have been better, but if it increased the cost of NICs during the early days, it may have prevented the widespread acceptance of Ethernet, so I'm not really concerned.

--
Rich Seifert             Networks and Communications
                         Consulting
rich@richseifert.com     21885 Bear Creek Way
(408) 395-5700           Los Gatos, CA 95033

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

Помимо этого в статье немного статистики по количеству фреймов разной длины на AMS-IX и сколько тратится на заголовки, не будем говорить что впустую, но при большем размере MTU полосу можно было бы использовать эффективнее.

За всё надо платить, статья про скорость в вебе и сертификаты, которые тормозят этот самый веб, с примерами для Chrome и Firefox. Зелёный огонёк с названием компании в строке браузера стоит дороже всего. Теперь бы понять является ли это фетишем или реальной потребностью.

Тут, кстати, ещё красивый ASn продают 7007. К нему можно и красивых IP прикупить для полного комплекта.

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

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

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

Чем плох классический полудуплексный Ethernet для автоматики - отсутствием определённости, в первую очередь в интервалах передачи, так как всегда присутствует фактор коллизии которую надо героически преодолевать. Не скажу за другие промышленные протоколы которые упоминаются в статье, но, например, в CAN коллизия как таковая отсутствует, конфликт решается жёстким определением приоритетов у контроллеров на основе его адреса и способа формирования сигнала в физической среде. Да, сам контроллер может заглючить и захватить полный контроль, но от глюков вообще мало кто застрахован.
Ethernet (полнодуплексный) в режиме точка-точка ограничен количеством подключаемых устройств, потому что между каждым из них надо организовывать среду передачи. В общем и это решается - полингом или передачей токена и один из вариантов такого решения в статье приводится. Это конечно свойство протокола, но уже, по сути, логическая надстройка над первым уровнем.

Так что мне думается, что просто так у Ethernet не получится вытеснить привычных "старичков" из этой ниши, тем более что это уже далеко не первая попытка. Инструменты подбираются под задачу, а не наоборот.

P.S. А CAN в самом деле интересный и не сложный в своей основе, про него стоит почитать для расширения кругозора и понимания, как у них там.  Я в свое время на целую дипломную работу начитал.

Ещё немного Habr - хорошее описание использования специальных мультикаст link-local адресов IPv6. Однажды я так перезагрузил ядро нашей сети выполнив ping ff02::1 непосредственно с центрального коммутатора. Было это конечно давно и наверняка подобные глюки фазы роста уже не будут проявляться, но это не точно.
Полный список того что определено глобально или для специальных целей.

Hello world впервые появился в книге про Си непосредственно от создателей языка Си. Даже в википедии про это есть. Книга была опубликована сегодня в 1978 году, что позволяет нам отмечать день Hello world, неизменный атрибут программирования на любом языке все эти годы.

Cacti рисует самые красивые графики, мне нравится больше всех других систем мониторинга. Так что если пользуетесь, как мы, обновляемся обязательно, а то версию 1.2.8 немного поломали. Там есть нюансы в возможности использования уязвимости, надо быть залогининым, но не всегда.

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

Спасибо что помогаете, я очень за это благодарен. Если таки решились сделать сайт в стиле Windows, выбирать есть из чего.

Тут в последнем посте было про тему Windows95 для BS, если уж на то пошло то вот есть более качественная.
https://github.com/AlexBSoft/win95.css

А если от Windows устали и хочется соскочить, то вам сюда. Правда курс на английском.

Не совсем DevNet, но всё-таки если хотите начать изучать Linux, то бесплатный курс от Cisco Netacad, то что вам нужно. Мое мнение, что без базовых знаний линукса в понимании DevNet все же не обойтись.

Что вы узнаете пройдя этот курс:

1. Поймете основы командной строки Linux (CLI)
2. Выполните практические упражнения с использованием виртуальной машины Linux (предоставляется бесплатно)
3. Определите, подходит ли вам Linux или нет.
4. Научитесь базовой установке и настройке программного обеспечения Linux

Искал что-то подобное!- 🤩
Пройденный этап- 👌
Windows forever!-✌️

Хотите поделиться своим мнением? Добро пожаловать в чат - https://t.me/automate_devnet

#linux #free_course

Инженеры всегда были инженерами, людьми для которых нет проблем.

"Hello, world" на Python и Netmiko. Простой пример, настолько простой, что возможно даже плохой если захотеть использовать его в боевом режиме. В нём нет никакой такой задачи, кроме подключения и использования Netmiko, которую бы нельзя было решить используя менее избыточные инструменты. Как минимум расширения include и exclude в командной строке Cisco и не только это уже регулярное выражение. Во многих современных устройствах можно и полноценные конвейеры строить.

А если хочется что-то посложнее, то SSH отлично позволяет выполнять команды тут же при подключении и выходить после выполнения. Например, вывести все интерфейсы Vlan оставив заголовок (вторая строка в выводе):

$ssh admin@192.0.2.15 "show ip int br" | sed -ne "2p;/vlan/Ip;"

Interface   IP-Address   Status   Protocol
Vlan1       unassigned   down     down
Vlan15      192.0.2.15   up       up

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

Кто-то скажет: "Ага! Вот уже начинаются сложности и даже такой пример с Python может поспорить с нагромождением команд".  Конечно, всегда стоит помнить когда остановиться и прекратить писать однострочники в нескольких сотен символов, но тратить всю мощь Netmiko на вывод списка интерфейсов, так себе применение инструмента. Как простейший пример, в рамках первый раз попробовать - всё отлично, именно так и надо начинать, повторять свои ежедневные действия в консоли. В продакшн тянуть такое не стоит.

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

​Махнул не глядя.

На скриншоте не всё поместилось, выше ещё показаны начатые треки, у меня там CCNP SP. Но по сути нововведения ничего не меняют, даже упрощают: раньше было 4 экзамена на этот трек без учёта обязательного CCNA SP, сейчас только два если идти самым коротким путём, которым я скорее всего и пойду. Мой сданный в прошлом году SPROUTE зачёлся, но особой роли уже не играет.

А внизу ещё просроченные сертификаты, там у меня ветка Voice, которую отменили очень давно, точнее заменили на Collaboration что превратило мой CCNA Voice в два сертификата специалиста которые дожили аж до 26 января этого года, до истечения срока давности.

Ещё в новом интерфейсе можно запросто скачать свой сертификат в PDF, раньше надо было заказывать да ещё и оплачивать.

Обширный набор шпаргалок от команд терминала и баз данных, до вариантов использования Си. Не очень подробно, но про всё.

​Как в Google (облачные сервисы) формируют метрики доступности, обзорная статья по работе представленной на симпозиуме NSDI'20. Цель работы показать как формировать и использовать такие метрики которые были бы:

- значимыми, отражали реальное поведение пользователя;
- пропорциональными, адекватно выражали изменения опять же с точки зрения пользователя;
- применимыми, позволяли владельцу системы понимать почему доступность в это время снижалась.

Можно сказать что у них получилось создать новую метрику user-uptime. Вот такого графика как на картинке мне точно не хватает. В работе (не в статье) приводится много формул и примеров метрики на реальных данных, чего вполне должно хватить чтобы перенять опыт Google.

Конференция ещё не закончилась и не все докладчики выступили, но всё уже доступно для чтения, должно быть много интересного.