Несколько советов траблшутингу вопросов производительности на полюбившейся в 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 это таблица состояний трансляций, а не собственно передача трафика. Для этого нужна память и быстрый поиск по ней, которой вдоволь у центрального процессора и так мало в специализированных устройствах.

Если вдруг вы доверяете больше Cloudflare чем Yandex, то они тоже сделали семейный DNS: 1.1.1.2 - антивирусный, 1.1.1.3 - без порно.
Для тех кто доверяет Yandex - dns.yandex.ru, который уже лет 7 как такое сделал.

Если вы решаете свою проблему с помощью регулярных выражений, то у вас теперь две проблемы. Коллега поделился ссылкой mathiasbynens.be/demo/url-regex - разные регулярные выражения для проверки URL. Табличка со сравнением кто прав и кто не прав.
Автор сразу оговаривается, что даже технически правильные строки могут не валидироваться по его условиям, потому что это его условия и ему так надо. Но всё же IP адреса с 0 или 255 в последнем октете довольно часто встречаются и они правильные, это прямо типичная ошибка дилетанта. Да и не все частные диапазоны вырезаны.
Мораль, регулярные выражения это личное, за свои ошибки есть кого винить и их есть кому исправить, а вот за ошибки в строке скопированной из Интернета можно очень больно получить потом. Поэтому только сами и только то что нужно, тем более это совсем не сложно ;) и тесты, тесты, тесты с максимальным покрытием.

Интересное, чисто научное, исследование, в котором удалось добиться передачи со скоростью терабит в секунду по медной паре. На N+1 только обзор, саму работу можно читать на aip.scitation.org. В статье не раз упоминается знакомый нам DSL (на N+1 сделали непривычный перевод "цифровая абонентская линия"), но на самом деле там собрали волновод (это важно) совсем не похожий на обычную телефонную пару, хотя и говорят что это приблизительно она и есть. Дальше увеличили частоту до 200ГГц и измерили результат, который на 9 метрах составил более терабита в секунду, а на 15 метрах около 30 гигабит в секунду. Собственно, ещё упоминается что оптика имеет большую стоимость со ссылкой на статью из 2007, а значит перспективы у такого решения есть. Поживём увидим, тем и хороши научные работы: может быть и на настоящем DSL скоро доберутся хотя бы до гигабитных скоростей, но пока оптика рулит.

За локальные DC++, да, обидно, но тут копирайт сыграл бОльшую роль. Весь описываемый процесс, примерно, лет 15 занял, первые массовые безлимитные тарифы от 8кбит/с до 64кбит/с это где-то 2005-2007 год в завистмости от региона.

- «Ой, у нас каналы перегружены», в историческом порядке:

1. Основные генераторы интернет-трафика — Youtube/Netflix — проектируются с использованием клиент-серверной архитектуры доставки видео, и до сих пор используют только её.

2. Проводные провайдеры вводят дешевые безлимитные тарифы, пользователи перестают считать трафик.

3. Проводные провайдеры отказываются от бесплатных локальных ресурсов, DC++-хабов, BitTorrent retracker'ов, всё больше интернет-трафика.

4. Мобильные телефоны и коммуникаторы становятся смартфонами с малым объемом памяти, доступные цены на мобильный интернет.

5. Дешевые и быстрые безлимитные тарифы полностью вытесняют оплату по трафику у проводных провайдеров, пользователи перестают хранить медиафайлы: зачем, если можно скачать или слушать/смотреть во «ВКонтакте»?

6. ПО, ранее использовавшие p2p-архитектуру, переделывается под клиент-серверную (Skype), или становится нишевым (SIP).

7. Пиратские «онлайн-кинотеатры» завоёвывают популярность, торрент-трекеры теряют популярность.

8. Dropbox, Яндекс.Диск и компания: зачем хранить файлы на ПК и передавать между ПК/смартфоном в пределах домашней сети, если можно хранить в интернете?

9. Дешевые и быстрые безлимитные тарифы у мобильных операторов (но с ограничением p2p-сетей), производительные смартфоны с малым объемом памяти: зачем хранить музыку на смартфоне, если можно слушать со Spotify?

10. Интернет-цензура в России: часть сайтов перестаёт открываться по непонятным причинам, Always-on VPN в другую страну.

11. Массовое шифрование всего трафика в интернете, фактическая невозможность нормального/массового использования локальных кеширующих прокси-серверов.

12. Появление нескольких проектов распределенных интернет-сайтов и видеовещания, отсутствие их популярности даже для нишевого использования, отсутствие поддержки со стороны разработчиков браузеров.

13. Повальное шифрование трафика в интернете, превращение всего в клиент-серверную архитектуру, SSL Pinning в программах, DNS over HTTPS в браузерах.

Виден ли свет в конце шифрованного туннеля провайдерской трубы? За последние годы появилось, по меньшей мере, 2 серьёзных проекта: IPFS и ZeroNet. Первый функционально скуден, но поддерживается крупными игроками (CloudFlare) и сравнительно распространён, а второй — не в пример функционально продвинут, но не получает должного внимания. Также есть нишевые: PeerTube, DAT. Если не все они, то я не знаю, кто.

Забыл еще важную вещь: у абсолютно всех сервисов аудио- и видеовещания отсутствует функция скачивания файлов. Смотрите онлайн, слушайте онлайн.

https://twitter.com/ValdikSS/status/1246183074771107843

Очень подробно как дружить Ansible и Cisco IOS - готовые плейбуки и подробные комментарии к ним для разных аспектов настройки: маршрутизация, управление, все базовые и повседневные операции.
Следующая часть серии про JunOS и это ещё не конец.

Японский провайдер SAKURA internet рассказывает, не вдаваясь в детали, про свою систему мониторинга. Речь больше про TimescaleDB, но есть и про то как они на лету, от 2000 до 4000 запросов в секунду, выдёргивают маршрутную информацию с GoBGP и рисуют красивые графики в Grafana.

Подписаны все используемые префиксы в Королевстве Бутан. Можно слать свои поздравления. Наверное, стоит сказать что границы в Интернет, пока, условности и там свои границы в виде автономных систем. В Бутане их совсем не много.

Если всё ещё подбираете DHCP сервер для IPv6, то посмотрите на dhcpy6d, который за 7 лет дорос до версии 1.0. Внутри Python 3, всё доступно на Github. За ссылку большое спасибо нашему подписчику.
Набор функций достаточен для многих задач, при этом есть поддержка внешних вызовов, если уж совсем не хочется менять исходный код. Мы для экспериментов в IPv6 использовали тоже реализацию на Python, но совсем простенькую, до такой степени что всё решалось переписыванием и дописыванием логики в самом исполняемом файле и сейчас я даже не нашёл первоисточник этого скрипта. Но работал он вполне исправно, для нескольких тысяч абонентов точно.

Мне подсказывают, что есть ещё популярная библиотека на Go, которая используется во многих реализациях DHCP, например, в Facebook. Для тех кто может и хочет делать, в том числе, и специфические вещи. Ссылки на примеры реализации и законченные продукты есть в readme.
Не забываем и про классику, так что выбор есть, помимо того, что можно и своё писать, или вообще принять что DHCPv6 не нужен.

Спецификация 800 Gigabit Ethernet

6 апреля 2020 года консорциум "25 Gigabit Ethernet", первоначально созданный для разработки спецификаций Ethernet 25, 50 и 100 Гбит / с, объявил, что изменил свое название на "Консорциум технологий Ethernet" - Ethernet Technology Consortium.
Это позволит "отразить новый акцент на более высокоскоростных технологиях Ethernet."

https://ethernettechnologyconsortium.org/press-room/press-releases/25-gigabit-ethernet-consortium-rebrands-to-ethernet-technology-consortium-announces-800-gigabit-ethernet-gbe-specification-152/

Одной из первых спецификаций, которую отстаивает Консорциум является спецификация 800GBASE-R для 800 Gigabit Ethernet (GbE).
Высокая скорость достигнута за счёт использования восьми линий со скоростью 106 Гбит/с.

Спецификация стандарта Ethernet 800G - https://ethernettechnologyconsortium.org/wp-content/uploads/2020/03/800G-Specification_r1.0.pdf