Отладка на IOS XR станет не то чтобы проще, но по крайней мере появятся новые её возможности.

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

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

Cacti таки сломался после 1600000000 секунды Unix эпохи. Удивительно, что сломаться не должно было - это не круглое двоичное число, никакие счётчики не переполнились, но всё равно сломалось. А я ещё подумал, что что-то такое должно было произойти, когда писал новость, спасибо коллеги заметили :)

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

Между IPv6 и IPv4 почти нет никакой разницы - исследование CDN Netflix. В целом, не только про IPv6, интересно наблюдать как за эти годы 2016-2019 изменился сам Интернет. Скорости подросли, пинги упали, а повсеместные локальные кеши, которыми с охотой делится не только Netflix, ещё на порядки меняют эти показатели. Интернет, во многих случаях, не где-то там далеко, а в ближайшей серверной вашего провайдера, более-менее крупного. Новая жизнь локалок, только теперь брендированных.

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

И это хорошо, IoT, хайп по поводу которого вроде прошёл, может стать отличным буксиром для вытягивания IPv6 в большой Интернет. В любом случае хуже не будет, так как похоронить его, сделав нишевым для промышленности уже не получится. Кстати, про RPL мы уже писали.

Заметки на предмет тюнинга sysctl networking

Интересный сабж на тему оптимизации:

https://bl.ocks.org/magnetikonline/2760f98f6bf654d5ad79

Не самое заметное событие, по сравнению даже с первым, но всё же. Если хотите оставаться актуальными при работе с вашими DNS, то стоит почитать и начать применять соглашения в рамках DNS Flag Day 2020 - продолжаем тюнить EDNS и обязательно включаем TCP в обмене. Тем более что команда собралась приличная.

Про типичные параметры настройки SSH клиента в файле ssh_config. Во второй части статьи много внимания уделяется ssh-agent и тому как заменить его на ProxyJump, по соображениям безопасности. Всё с конкретными, простыми примерами.

Я, кстати, перебрался на SuperPuTTY c PuTTY Session Manager. Не скажу что почувствовал сильно большую разницу. Второй висит в трее, не занимая места на экране, и прямо оттуда можно запускать нужный сеанс. А SuperPuTTY вкладки делает удобно. В плане организации управлением базой хостов, что то, что другое одинаково.

Хорошо конечно, но, на мой взгляд уже поздновато, как минимум для России. IPv6 как инструмент обхода блокировок хорошо работал ещё года 3 назад, но сейчас уже не так хорошо. Есть конечно свои особенности и плюсы из-за использования публичного адреса. Например, можно строить ассиметричные маршруты один конец которого в туннеле для исходящего трафика который режется провайдером, а второй прямой. Но, все кому надо уже научились, да и публичный адрес упрощает работу по поиску и идентификации источника, всё же с NAT это сложнее было сделать.

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

Ситуацию, во многом и пока решает кеширование. Для DNSSEC ещё и новый RFC8198 позволяющий сразу исключать из проверки целые группы имён в алфавитном порядке за один запрос/ответ. Он же помогает и в случае NXNSAttack, вы же подписали и поддерживаете DNSSEC в своих зонах?

Другой подход - каждому держать свою копию корневой зоны. Опять же, вопрос её достоверности должен решить DNSSEC, а вопрос распространения - строго заданное расписание публикаций. С CDN и раздачей статических файлов, худо-бедно современный Интернет научился справляться. Но для этого придётся изменить правила, сразу и для всех, чего добиться будет ой как не просто, тем более что всё ещё есть альтруисты в этом мире.

Я в общем не вижу больших проблем, даже наоборот, вижу преимущества использования различных инструментов для различных задач. Да, есть много вопросов связанных с управлением зоопарком программных продуктов, все они обоснованы и понятно желание навести в этом порядок.

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

В остальном, разнообразие инструментов, особенно, возможность пробовать новые инструменты только положительно сказывается на деятельности. Возможность не замкнуться в рамках одного подхода и одной идеи, видения одного вендора, часто приносит много положительных результатов.

Так скоро и Неуловимых Джо не останется.

Окей, эта история просто заслуживает войти в the best этого канала!

Короче, некто сжёг автомобиль у дома свидетеля, который проходит по делу певца R. Kelly. Федеральные органы запросили у Гугл информацию о всех пользователях, которые искали в Гугле адрес, по которому проживает этот свидетель, в рамках времени, когда произошёл поджог. Этот запрос с ордером привёл к запросу с определённого IP-адреса в соседнем штате за пару дней до поджога. IP адрес принадлежал телефону, который был записан на некоего гражданина. Который оказался родственником издателя певца R. Kelly. Затем представители правоохранительных органов проанализировали логи с базовых станций вокруг дома, где был подожжен автомобиль. Сюрприз-сюрприз, в логах БС оказался тот же телефон, принадлежащий уже установленному гражданину, и по логам он там фигурировал прямо во время поджога. Агенты арестовали его, и в телефоне обнаружилась информация о поездке в день поджога, с остановкой возле места, где произошёл поджог. Такой вот цифровой след. Детали расследования по ссылке в документе

https://www.documentcloud.org/documents/7222789-Another-R-Kelly-Search-Warrant.html

В общем-то ничего невероятного, если вы в принципе ведёте и имеете потребность в формальной документации по сети. Для многих хватает оперативной, совмещённой с активными системами мониторинга/учёта/управления, откуда можно надёргать всего и разного в любом виде. Кстати, провайдерам как никогда эта задача становится актуальной в связи с "законом о суверенном интернете" и требованиями РКН по заполнению формальных машиночитаемых XML шаблонов с топологией сети, составом оборудования, точками присоединения...

CloudFlare запустили совсем неочевидный массам продукт Cloudflare One - это такой комплексный инструмент для построения ваших собственных (корпоративных например) сетей. Идея в том, чтобы с помощью простого приложения создавать ваши собственные приватные сети так, чтобы вы и ваши сотрудники могли воспользоваться всеми вашими внутренними сервисами, а внешние люди нет. Конкурентов у Cloudflare One много, два самых явных это ZeroTier и TailScale - функции те же самые. Главное отличие нового продукта - интеграция с другими системами идентификации пользователей, по сути вы можете сделать виртуальную сеть для всех, кто из вашего домена (если он заведен на google workspace например).

Понимаю что сложно, но вообще это потенциальная революция в мире корпоративных VPN решений https://blog.cloudflare.com/introducing-cloudflare-one/

Если вам привезли кучу цисок, которые вам надо обновить прямо сразу как вы достали их из коробок, то путь ваш лежит в царство маловнятной магии с hex параметрами для вашего DHCP.
Однако добрые люди перевели на человеческий эту часть недокументированных знаний.
https://vincent.bernat.ch/en/blog/2020-dhcp-cisco-ios

Так что, нужны сетевики или нет? Наверное, телефонистам очень обидно, про них вообще не вспоминают :). Большой привет всем телефонистам, коллегам и не только, вы нужные и полезные, без сомнения.

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

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

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

Как ни крути, все кто сейчас это прочитает, прочитает потому что сетевики постарались. Интернет всё ещё и во многом именно Net - от вашего провайдера, даже самого мелкого, проводного или сотового и до гигантов индустрии, где в каждом есть свой, совсем не мифический и не исчезающий профессионал по сетям, а часто целый отдел.

И тут привет всем сетевикам от сетевика, отдельный @Night_Snake и @Linkmeup :) и всей нашей общей, не большой, но тёплой сетевой Телеграм компании.

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

Чтобы было с чем сравнивать. По трафику современные устройства на границе сети у провайдера могут перелопачивать десятки гигабит/c, включая NAT и нарезку скоростей каждому абоненту в одной коробке. Каналы в Интернет, соответственно, тоже где-то в этом диапазоне от единиц до сотен гигабит/c. Tier1 и Tier2 в своих пресс-релизах хвалятся суммарной пропускной способностью во всех направлениях в единицах терабит/c.

Гораздо важнее PPS, типичные значения - несколько миллионов пакетов в секунду на устройство, опять же включая NAT и нарезку скорости, а не просто маршрутизацию и пересылку трафика. По графикам Google здесь видно многократное превышение, но тут скорее всего мы имеем дело с суммарным значением распределённым по многочисленным точкам присутствия, а не атаке пришедшейся на одну точку. Как это работает можно послушать в докладе IVI на PF2018.

А вот RPS мне не с чем сравнить, но тут дело не в количестве а в качестве, можно и одним запросом много дел натворить.

Последнее время часто стали попадаться на глаза симуляторы работы сети, чтобы придумать и построить топологию, задать начальные условия и посмотреть что в итоге вышло. Ещё один, вот настолько простой насколько можно, при условии, что надо уметь в Python - NeST и вводная статья про него на APNIC. Простейшая топология умещается в несколько строчек:

n0 = Node('n0')
n1 = Node('n1')

(n0_n1, n1_n0) = connect(n0, n1)

n0_n1.set_address('10.0.0.1/24')
n1_n0.set_address('10.0.0.2/24')

n0_n1.set_attributes('5mbit', '5ms', 'pfifo')
n1_n0.set_attributes('10mbit', '100ms', 'pfifo')

flow = Flow(n0, n1, n1_n0.get_address(), 0, 10, 2)

exp = Experiment('tcp_1up')
exp.add_tcp_flow(flow, 'reno')

exp.run()

Пока очень скудно с документацией и примерами, но можно читать исходный код и, скорее всего, авторы будут рады пообщаться.

Просто замечательный пост для адептов Juniper про commit check.

Я сам частенько делаю сначала commit check, а сразу потом commit. Тут дело не во времени, пока мои конфигурации не выросли до таких размеров чтобы применяться по 15 минут. Дело в уверенности, пусть это и чисто психологический момент. Ведь технически нет никакой разницы - commit в любом случае проверит конфигурацию на синтаксическую корректность перед применением. Но когда процесс финального применения внезапно прерывается ошибкой, где-то начинает грустить один администратор. Это как спотыкнуться и упасть перед самым финишем.

Настоящие инженеры не должны поддаваться и идти на поводу у чувств и тратить своё время зря. Настоящие инженеры используют commit confirm, а уже потом commit check.