Патчкорд

Помогло бы расширение канала? Возможно, но не обязательно. Как ещё один слой QoS, несомненно, добавляет много сложности, порой очень много, когда пересекаются интересы разных участников и разных сетей. Помните про это и будьте готовы, я однажды вольно пересказал, нарисовав те графики которые хотел, маленький кусочек учебника Cisco по QoS от Odom и Cavanaugh, остающийся актуальным до сих пор, с него можно начать.

Разница между приоритетной очередью (после 10:00) и общей, в оценках Cisco IP SLA MOS (более наглядный верхний график, оценку следует поделить на 100, максимум тут 4,34 из 5) и потерь пакетов (нижний график). Очередь формируется с двух сторон на исходщяем трафике в арендуемый канал, который загружен по средней пятиминутной оценке до 60-70%.
Субъективно такие потери не ощущаются, да и другими инструментами такое не всегда чётко удаётся наблюдать, простому ping не хватит масштаба, нужен какой-то постоянный трафик с нумерацией пакетов a'la RTP, что собственно и реализовано в одном из режимов измерений IP SLA.

пу-пу-пу 🤔

Инструмент с помощью которого можно визуализировать большие сети, в частности Интернет (связи между AS) , как показано в примерах. Написано на Python, выглядит просто и красиво, может быть слишком геометрично, есть возможность поиграться параметрами.

Страх интернетчика номер один - увидеть свою AS в публичных отчётах утечек/hijack BGP. У автора в итоге ничего страшного, но пиринг есть пиринг, даже если он чисто технический, внутренний и для исследовательских, альтруистических целей.
Мне несколько раз, и даже не на заре своей карьеры, приходилось упускать частные сети наружу, без последствий. Пару раз спасали фильтры апликов вплоть до отстрела BGP сесси, но что-то увидел уже в публичном LG. Остаётся пожелать всем быть внимательным, чтобы такого с вами не случалось.

Итак, я уже давно пропагандирую использовать netlab для своих лаб
И давно пропагандирую отказываться уже от legacy EVPN\VXLAN изучать EVPN VXLAN
И если вы всё ждали знак свыше, что бы сделать или то или сё или всё вместе - то вот вам целых два (2!) знака.
Отвертеться не получится больше. Кто не юзает netlab - тот козявка теперь.
Ныть о том что "му-хрю нету русских статей про netlab и evpn\vxlan" больше нет никакого права.
Встречайте

Книга от Дмитрия @aeangel - https://aeangel.gitbook.io/netlab_for_otus
Книга от Александра @Sloukot https://mr-grin93.gitbook.io/netlab-homeworks

В работе Димы для меня было новым использование инструмента EdgeShark (https://netlab.tools/extool/edgeshark/) - живая капча по клику мышки!
А Саша открыл для меня возможность запуска лаб прям в codespace (https://github.com/features/codespaces) - ну то есть теперь ваще ничего не надо у себя держать, хватит просто аккаунта на гитхабе

Крайне рекомендую ОБЕ работы. Потом ещё раз пару раз.
И если после этого будете на собесы приходить без знания EVPN\VXLAN то я даже не знаю ваще чё вам ещё надо-то в жизни

MTR для Linux и Mac на Go, с отображением параллельных маршрутов.

Спасибо самым лучшим подписчикам за ссылку. SSH это SSH, а TLS это TLS, ассиметричная криптография и там и там, но реализация этого разная. А в доверии TLS сертификатам, может быть скоро, нас ждут большие изменения. Кстати, вы же проверяете fingerprint SSH перед тем как добавляете хост в доверенные?

Смотрим какие внутренние севрисы используют компании (через TXT записи)

Люблю подглядывать, какие сторонние сервисы используют внутри компании через DNS записи:

dig txt apple.com

Это записи подтверждения владения доменом для интеграции со сторонними сервисами.


Видим что внутри 🍎Эпла используют:

Miro
Atalssian
Adobe
Cisco
Dynatrace
Три верификации для Google
Фейсбук, Yahoo

Любопытно.

Cloudflare про BGP зомби - зависшие маршруты ведущие в никуда и как надо поступать, чтобы минимизировать риск их возникновения. Сосредоточились, в основном, на моментах смены маршрутов и вызванной этим паузой, но недавно прямо в протоколе одну из возможных причин починили. Интернет это глобально, поэтому надо запастись терпением и делать всё по шагам.

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

Как в Cloudflare определяют CGNAT, с помощью RIPE Atlas трасировок, PTR, списков VPN и машинного обучения по поведению клиентов. Пишут что со скоростями за NAT дела обстоят хуже чем без него. В Африке NAT больше всего и большее количество абонентов упаковывается в один адрес.

В любом расследовании главное не выйти на самого себя. Анализ пакетов TCP SYN с полезной нагрузкой, в котором обнаружено что 75% анализируемого трафика приходится на трафик исследователей. Из оставшегося, досталось Zyxel и непонятным TLS запросам, а 5% никак не классифицировали.

GoBGP дорос до версии 4, не пропускайте.

Ещё раз напоминание от Ивана Пепельняка, что RFC никому не указ, на этот раз с таймерами OSPF. Интересный момент в этой истории, о чём собственно говорится в RFC1925, что netlab будет поправлять такое поведение, что добавляет ещё один слой сложности, который теперь влияет на поведение, пусть и внутри лабы, и про который надо помнить, потому что изначальное поведение тоже может измениться. И так далает, наверняка, не только netlab, и вот этот слоёный слипшийся пирог мы едим каждый день.

Какая пятница такие и мемы.

Сейчас всё уже работает, потому что Интернет ещё держится на доверии и это то для чего вы должны иметь актуальные abuse контакты в RIPE DB и реагировать на них. Если что-то не видно от вас, может быть видно кому-то со стороны. Исторические данные по RPKI доступны на ftp.ripe.net, ищите файлики roas.csv по датам. История маршрутов доступна на stat.ripe.net. Наверное, такая ситуация не единственная, просто мало кто ещё фильтрует трафик по ROV. Фильтровать только у себя, не всегда работает. Мы добавили ещё один слой и он ломается, там тоже можно ошибиться, стало сложнее, это плата за хоть какой-то технический контроль внутри BGP. Пионерам RPKI респект, остальным надо подтягиваться, просто подписей недостаточно, надо фильтровать.