Ещё раз про сетевую гигиену, не только про маршрутизацию, про DNS и про фильтры и самые общие подходы ко всему.
Конкретно про RPKI (PDF), от начала и почти до конца. Упущен момент настройки RPKI валидатора, но зато есть все настройки для Cisco и Juniper с выводом результатов. Документ представлен, в том числе, точкой обмена трафика NAMEX в Риме - вот у них трафик подрос очень серьёзно, почти в два раза, по среднему годовому потреблению.

В связи с ростом внимания к VPN вспомнили и про Cisco ASA, дружеские отношения с которой у меня так и не сложились. Несколько коротких видео с базовыми операциями по настройке от Katherine McNamara: интерфейсы, доступ, NAT(PAT) и VPN, бонусом ISE. Примеры для ASDM и обычной консоли.

IPv6 PTR DNS выглядит "смешно" в Windows DNS

В шапке группы ссылка на подключение. Не упускайте момент.

Компания Cisco проводит марафон "Корпоративные сети - Все по порядку".

Ежедневно в 10-00 до 12-00 проходит лекция эксперта Cisco по технологиям для корпоративных сетей. В конце каждой лекции предусмотрена сессия вопросов и ответов. Дополнительные вопросы экспертам можно задавать в группе в течение всего марафона.
Материалы лекции, а также дополнительные материалы для самостоятельного изучения публикуются в группе в тот же день после лекции.
Домашнее задание публикуется в группе в тот же день после лекции.
Обсуждение домашнего задания и ответов в группе допускается и приветствуется.
Разбор домашнего задания проводится экспертом в начале лекции следующего дня.
По окончанию марафона наиболее активные участники получают памятные подарки.

Официальная группа марафона @CiscoENmarathon

Не могу пройти мимо. На Хекслет перевод заметки Дейкстры 1982 года, про то почему нумеровать с 0 правильно. Сколько шуток и холиваров по этому поводу прошло мимо меня в студенческие годы, а тут оказывается можно под это подвести какую-никакую, но математическую основу. Главное не переусердствовать, чтобы не превратиться в героя многих анекдотов про программиста.

Facebook запустили сервер точного времени - time.facebook.com, говорят самый точный из известных публичных. Почитать что там под капотом и почему chrony можно в статье на engineering.fb.com.

Листаю книжку по VMware, а там забавный костыль для vSwitch - чтобы сделать порт транковым надо назначить туда вилан 4095. Я даже удивился, зачем сэкономили на галочке хотя бы, при том что в Distributed Switch всё есть, не говоря уже про другие решения. Это не имеет значения сейчас, но может аукнуться потом, когда вдруг все решат использовать 4095 для чего-то другого, как, например, с адресом 1.1.1.1. Я конечно утрирую, но прямо бросается в глаза.
А так, сеть как сеть, ничего сильно необычного что вполне можно было бы придумать в виртуальной среде нет. Это логично, сохранять привычные интерфейсы и механизмы взаимодействия, но тогда 100% этим должен заниматься не условный админ серверов, а админ сети и будет всем счастье. Может быть когда-то это всё спрячется так глубоко что уже и не откопаешь, но пока не так.

IHR обновили свой сайт: можно всякую статистику смотреть по сетям и странам, внутри анализ RIS, BGP и активный мониторинг RIPE Atlas. Стало, наверное, красивее, функционально осталось то же.

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

Fullstack mailserver based on OpenSMTPD for OpenBSD using ansible

https://github.com/AnsiMail/AnsiMail

#ansible #opensmtpd

Вчера у ISC были технические проблемы из-за чего bind с настройкой dnssec-lookaside сломался, что вызвало проблемы в работе DNS которые достаточно бурно обсуждали в тематических сообществах. ISC честно обо всём написали сегодня и извинились, но напомнили что этот режим, как минимум, три года под запретом использования.

Классическая история - если ты что-то сделал в Интернете и этим начали пользоваться больше двух человек, то просто так это не отключишь. Вторая история - это сделали чтобы обойти (не решить) существующую на тот момент проблему RFC4431. И третья история - никто не смотрит конфигурацию которая работает, пусть она и была настроена 10 лет назад.

В общем, стоит сходить по ссылкам в письме и не забывать обновлять свои настройки и версии ПО: bind 9.16 и новее - опцию не поддерживает, 9.12 - не запустится если она включена.

Несколько советов траблшутингу вопросов производительности на полюбившейся в SP сегменте (b2b, b2c) платформе ASR1000:
- в старые SIP-10 не имеет смысла вставлять больше одной SPA-10G не смотря на наличие 4 слотов под SPA.
- старайтесь не пропускать через интерфейсы с ip nat inside/outside много трафика, который не нуждается в трансляции адресов. ip nat outside на интерфейсах, где он не нужен тоже понижает производительность маршрутизатора;
- обязательно собирайте значение по загрузке QFP (Input Priority, Input Non-Priority, Input Total) через SNMP (CISCO-ENTITY-QFP-MIB). В консоли эти цифры можно получить в выводе команды sh platform hardware qfp active datapath utilization.

При использовании множества фич (например Netflow, NAT) можно столкнуться с проблемой роста overrun на интерфейсах, при этом также будет характерная полочка на графике загрузке QFP, не смотря на кажущийся запас по производительности.
В данном случае надо вспомнить немного про архитектуру платформы. SIP для входящих пакетов производит классификацию и распределяет их по двум очередям low (Non-Priority) и high (Priority). По умолчанию трафик c с метками TOS, MPLS EXP, CoS 6 и 7 попадает в Priority очередь. Трафик из Priority очереди достигает ESP первым, причем если QFP будет перегружен, то для трафика из low очереди будут генерироваться pause frames до тех пор пора хватает буфера на SIP. В это же время трафик из high очереди будет нормально обрабатываться.
Также есть, предположение, что для high очереди есть выделенный канал в DRAM (подтверждения этой информации нет).
Для того чтобы трафик перенаправить в high очередь:
- покрасить на соседней железке часть трафика метками согласно настройкам по умолчанию;
- если в сети уже настроен и используется QoS, то можно на интерфейсах маршрутизатора изменить настройки по-умолчанию используя команды plim qos input (Подробнее можно почитать на https://www.cisco.com/c/en/us/td/docs/interfaces_modules/shared_port_adapters/configuration/ASR1000/asr1000-sip-spa-book/asr-spa-pkt-class.html)

На практике при распределении близком 1 к 1 удавалось достичь более высокие показатели пропускной способности при отсутствии overrun на интерфейсах. Характерная полочка с графика загрузки QFP также ушла.


Полезные команды:
- show platform
- show platform hardware qfp active datapath utilization
- show platform hardware port ... plim buffer settings detail
- show platform hardware port ... plim statistics

Серия статей про новый стандарт 100G-FR и трансивер Cisco в котором 100G достигается не расширением полосы, а прямо помещается в одну лямду, стандартный диапазон. Что упрощает сопутствующую оптическую обвязку, а с другой стороны увеличивает возможности уже существующих оптических сетей. 100G уже совсем на пороге, наверное многим можно будет и 40G пропустить, если до сих пор дотерпели.

Пример эксплуатации уязвимости в CDP на NX-OS начиная с организации рабочего окружения на GNS3, а после описания причин ошибки, плюс совсем немного кода и теории о стеке, его переполнении и как это использовать.
Обратите внимание, что CDP (не только он) реализуется обычной 32-битной программой, отдельный файлом cdpd для Intel совместимых процессоров, для анализа которого не надо каких-то специфичных инструментов. Унификация и переносимость играет в обе стороны - код проще и быстрее писать и в то же время проще и быстрее находить в нём ошибки, перестраиваться не надо.
Cisco.com про это - не забывайте обновляться.

На MSK-IX рекорд по трафику, наверное, и на других наших обменниках, но там статистики нет такой наглядной. В чатиках обсуждают общий рост от 15-25% у провайдеров, могу в принципе сказать то же самое за нас, но у нас уже случился сезонный спад поэтому сейчас мы отыгрываем позиции. Профиль трафика в общем типичный для выходного дня - его равномерно много с утра и до вечера, потом резкий рост до пиковых значений с 20 до 22 по местному времени. Обычный трафик буднего дня значительно меньше и вечерний пик гораздо резче, при этом в обед, как правило, происходит его спад. Это видно, в том числе, и на недельных графиках MSK-IX.
Заметьте, что пик трафика всё равно вечер, т.е. это нагрузка не рабочая, за неимением возможности получить развлечения другим путём оно получается через Интернет, где в том числе и Телевизор уже давно живёт. Посмотрим что будет дальше, пока всем нам очень далеко до гигантов вроде Azure, которые рапортуют о 775% !!! росте потребления.

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

Всемирный день бэкапа

- проверь резервные копии
- проверь расписание резервного копирования
- задумайся над тем, все ли, что необходимо находится в резервной копии
- вообще, есть ли у тебя бэкапы?)

Не будь дураком в апреле:

https://www.worldbackupday.com

Verizon Media про свои внутренние инструменты и кухню. Мало деталей, разве что названия инструментов привели и общие принципы, но можно посмотреть на графики и увидеть что инженеры работают и показатели улучшаются. Про BBR у них отдельная статья есть, вывод тот же - оптимизировать только то что надо.

NAT как корень необходимости тратить больше вычислительных и портовых ресурсов на передачу трафика. Тест пропускной способности Linux из коробки - 14Mpps 64 байтными пакетами, даже с включенным, хоть и с минимальными правилами iptables. В реальности, наверное, будет похуже, хотя тут даже не делается попытки тюнинговать систему. Но если сравнивать даже этот тест, то NAT роняет пропускную способность в 6 раз в многопоточном исполнении. Кстати, цифры около 3Мpps, очень близки к тем что обещают многие вендоры для своих сервисных плат.

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