Помните же что в Windows есть свой SSH. Статья про то как и где он хранит приватные ключи, точнее ssh-agent, и как их оттуда можно достать.
Береги свой ключ смолоду!

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

Что-то стало с современными L3 свичами low-end операторского сегмента. Куда ни ткнись все стали пилить подобие Cisco like интерфейса. Даже D-Link, получается прямо криво - чувствуется что довлеет предыдущий подход поверх которого плохо лёг новый cli.

А ещё все сломали ACL - можно только на физический порт (для всех виланов разом, хотя хочется раскидать по svi), плюс некое подобие VACL. Бывает в классическом варианте без направлений, а бывает что можно in/out задавать для вилана прямо. Полезная штука, но если хочется делать L3 и немного транзитных виланов, то вот эти два варианта ни к селу ни к городу.
В общем что-то у меня сломалось с восприятием новой концепции. Внезапно, классический D-Link интерфейс кажется очень хорошим - другим, но хорошим.

P.S. Про MPLS молчу, но его тоже везде впилили, каждый коммутатор отметился, прямо каждый. Наверное, потому что могут.

Интересный проект "народной" базы с точками доступа WiFi. Хорошо видно как провайдеры именуют точки доступа которые ставят абонентам, и насколько случайные-неслучайные пароли используются.

Yandex DNS семейный 77.88.8.7 сегодня, примерно с 4-х утра судя по нашему мониторингу, начал находить на vk.com материалы для взрослых. Раньше не находил. Теперь DNS возвращает ответ на страницу Yandex.

>host vk.com 77.88.8.7
Using domain server:
Name: 77.88.8.7
Address: 77.88.8.7#53

vk.com has address 93.158.134.250
vk.com has IPv6 address 2a02:6b8::b10c:babe
vk.com mail is handled by 0 mx.vk.com.

>whois 93.158.134.250

inetnum:        93.158.134.0 - 93.158.134.255
netname:        YANDEX-93-158-134
status:         ASSIGNED PA
country:        RU
descr:          Yandex enterprise network

Дети останутся недовольны.

Абоненты находятся за границей сети, так же как и пиринг партнёры и апстрим провайдеры. На границе сети должен быть контроль - тотальный, в меру возможности тех устройств которые там стоят. Статья про Route Target в MPLS, про то что никто никому не запрещается делать так как хочется. Поэтому надо фильтровать или безоговорочно переопределять. Обычно это всегда можно сделать тем или иным способом.

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

policy-map pClear-input
class class-default
  set ip dscp default

interface Gi1/0/1
service-policy input pClear-input

Для коммутаторов и того проще, скорее всего, на порту надо определить метку которой трафик будет в дальнейшем принадлежать. Но если в сети уже распланирован QoS то здесь не должно возникать сложностей, просто стоит об этом помнить.

Когда твоя домашняя лаба, выглядит как серверная не самого мелкого провайдера.

А у нас нет фальшпола и фальшпотолка нет. Зато есть холодный и теплый коридоры. И вообще, я чертовски давно в серверной не был, но это хорошо даже :).
Вот эти вот кабели - основа всего, никакие админы не нужны будут если вот тут ничего не будет. А выглядит это примерно у всех одинаково.

$ whoami
ubuntu

$ whereami
In a Docker container. Inside a Kubernetes cluster. Running in a VM. On top of a Hypervisor. In someone else's datacenter.

$ howdidigethere
No. Fucking. Clue.

Интерактивная карта подводных кабельных магистралей. Можно щелкать, смотреть какая длина, точки выхода, кто владелец. Можно почитать, что вообще к чему и как устроено.
Есть ещё и другие карты на telegeography.com.

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

h1>tracert  192.0.2.102

 1    1 ms     1 ms     1 ms  203.0.113.1
 2     *

h2>tracert  203.0.113.101

 1    1 ms     1 ms     1 ms  192.0.2.1
 2     *

Сразу видно куда надо зайти чтобы выполнить show ip route. Но такое случается оооочень не часто. Чаще внезапно, ломается FIB или CAM или непостижимым образом трафик начинает дропаться, при всех прочих рабочих показателях.

У всего есть причина, но если она за гранью твоего понимания и знаний то начинается ремесло и шаманство, часто приводящее, например, к перезагрузке устройства по cron. Потом это выливается в верное решение или нет, но искать его надо обязательно.

​В день IPv6 тест - насколько хорошо вы представляете себе распространение IPv6 в мире.
Я вот совсем не представляю, думал что больше.

Не столько IPv6 сколько посмотреть на другую для меня реальность. Пока ещё ни разу не сталкивался с Nokia (Alcatel-Lucent): минимальные настройки интерфейсов и проверка этих настроек.

Кароче, зацени – нашёл лицензию для наших скриптов

https://github.com/me-shaon/GLWTPL/blob/master/LICENSE

Когда устройства не предназначены для монтирования в стойку получается или полный бардак или почти произведение искусства. У меня вот дома тоже EdgeRouter X, но он скромненько висит на проводах за столом :)

Sticky ECMP в IOS XR - крутая штука, делает из ASR9000 прямо балансер, почти настоящий.
В провайдинге это не принципиально, наверное, хотя вот эти всякие туннели - ладно, нам это не так принципиально. А вот хостерам для балансировки самое оно, но у них наверняка что-то специальное уже есть.
Примеры настройки и результаты работы, с глубоким погружением в детали - присутствуют.

Всё что можно покрутить в Linux для производительности сети. Объяснений не много, но список большой: включая прерывания, буферы, очереди, параметры TCP. Поэтому крутить надо умеючи или от большой скуки.
Есть картинки, набор команд для мониторинга и много ссылок.

​Подтверждаю, что каждый из 10 пунктов - классика ошибок, прочувствовал на своей шкуре не один раз.
Однако самый коварный враг в траблшутинге не незнание конкретной проблемы, а решение не той проблемы, особенно в случае применения "экспертного" подхода. Когда решение начинается с попытки ударить сразу в нужную точку, можно потерпеть сильно бОльшую неудачу.
Всегда надо остановиться вздохнуть и выдохнуть и начать по порядку, как бы тебя не торопили. Я предпочитаю идти снизу вверх. И ещё, доверяйте своей системе мониторинга больше чем себе, она объективнее любого эксперта.

Juniper гораздо более детально описывает и реализует базовые концепты для работы протоколов маршрутизации. Чего стоит только набор из десятка разных таблиц живущих одновременно. А ещё градаций AD больше - можно сравнить с Cisco. И не надо бороться с петлями маршрутизации при редистрибьюции, когда каждый из протоколов существует в Internal и External ипостасях.

Новый Unbound реализующий RFC7816 по умолчанию. Это когда вместо www.foo.bar.example если оно не найдено в кеше, на следующий известный сервер для зоны, пусть .example -  ns.example летит короткий запрос bar.example. В общем, производится попытка отрезать предположительно ненужное, то что мастер серверам зоны знать не обязательно (privacy). Но это чревато повторными запросами иногда излишними, помним про PTR IPv6, или про то что сервер может знать больше или меньше чем мы предполагаем.
Unbound качаем тут, или в своём любимом репозитории.