А вот и презентации с прошедшего в Париже MPLS World Congress.

Вышел новый DAY ONE: JUNIPER AMBASSADORS’ COOKBOOK FOR 2019

Рисуем схему сети в YAML

http://go.drawthe.net

Прототип BNG disaggregation от DT. Control plane на x86, Data plane (User Plane) для BNG на свичах/чипах с Barefoot Tofino/Broadcom, включая такие фичи как H-QoS per sub, ACL per sub, LI, MPLS на uplink и др. Сам Dataplane конечно написан на P4 https://www.youtube.com/watch?v=eiylRjF9hYg

Небольшая работа "Resilience of the Internet Interconnection
Ecosystem" которую на русский можно перевести как "Упругость интернет экосистемы" включает в себя анализ природы Resilience как свойства системы, различные аспекты и характеристики интернета, как сложной системы, а так же конкретные рекомендации по улучшению resilience сети интернет. https://www.cl.cam.ac.uk/~rnc1/weisresilience.pdf Оригинальная работа называется "Inter-X: Resilience of the Internet
Interconnection Ecosystem"
P.S. Список обработанной литературы впечатляет.

Опубликованы материалы с прошедшей конференции Cisco Connect 2019:
https://www.cisco.com/c/m/ru_ru/training-events/cisco-connect/materials.html

Heavy Networking 445: An Introduction To The Nornir Automation Framework

Свежий выпуск подкаста Packet Pushers c Димой Фиголем про Nornir фреймворк!

https://packetpushers.net/podcast/heavy-networking-445-an-introduction-to-the-nornir-automation-framework/

Juniper Reports $1B Revenue for 1Q 2019, Down 7% Annually

У Juniper Networks в очередной раз упала выручка на 7%.

https://www.lightreading.com/cloud/network/juniper-reports-$1b-revenue-for-1q-2019-down-7--annually/d/d-id/751053

Видео с MPLS World Congress про SR dataplane

https://www.youtube.com/watch?time_continue=2&v=IhpNum6gA84

Cлайды с Juniper Networks Benelux TechClub2019

http://emea.juniper.net/TechClubBNLX2019_Presentations

Day One: Inside Segment Routing

Foundations of Modern Networking

FQ_CoDel (rfc8290) для решения Bufferbloat проблемы ваших этих интернетов https://gettys.wordpress.com/2018/02/11/the-blind-men-and-the-elephant/ https://tools.ietf.org/html/rfc8290

Рецепт красивого сбора и мониторинга syslog-логов используя Telegraf, InfluxDB и Grafana.

Monitoring logs from Docker containers and network functions (Cumulus, Cisco, Arista, Nokia) using Telegraf, InfluxDB and Grafana
http://karneliuk.com/2019/05/monitoring-logs-from-docker-containers-and-network-functions-cumulus-cisco-arista-nokia-using-telegraf-influxdb-and-grafana/

A DEEP DIVE INTO CISCO’S USE OF MERCHANT SWITCH CHIPS

https://www.nextplatform.com/2018/06/20/a-deep-dive-into-ciscos-use-of-merchant-switch-chips

Не смотря на весь хайп, но при этом действительно неплохие возможности, у Segment Routing очень много проблем для того чтобы избавить мир от нелюбимого (большинством) RSVP-TE прямо сейчас. Самые банальные и одновременно серьёзные из них все и так знают. Редко встретишь историю о TI-LFA.

Из каждого утюга доносится: SR поддерживает замечательный механизм FRR, он значительно превосходит своих IP FRR побратимов, и даже RSVP-TE FRR ему уступает, то в том, то в этом. И почти никто не говорит, что хорошо TI-LFA работает только в контексте SR, который сам по себе закрывает достаточно обширную нишу, но при этом не является тем, ради чего мы все сегодня собрались. Гораздо более важный груз ответственности лежит на SR-TE, без которого о какой-либо замене RSVP-TE говорить не приходится. И тут возникает один нюанс, который редко встретишь в евангелистских докладах.

У TI-LFA есть определённые сложности в работе с SR-TE. Так как весь LSP закодирован в пакете, опираясь на основной принцип работы MPLS, PLR может принимать решения о защите LSP имея на руках только метку на вершине стэка. Это первое фундаментальное отличие от RSVP-TE, в котором благодаря сообщениям Path каждый LSR в рамках LSP знает его endpoint. В SR же под защиту подпадает не весь LSP, а только лишь конкретная метка в конкретный момент времени и это второе отличие от RSVP-TE. Третье же отличие состоит в том, что в рамках SR метка имеет определённую семантику, — Node SID, adjacency SID, etc. — которая доступна благодаря единой LSDB.

На минутку прервёмся и вспомним, как работает TI-LFA. Если очень коротко, то данный механизм исключает из топологии рёбра и/или вершины, которые гипотетически вышли из строя, и запускает по ней SPF. При этом сохраняются все свойства LFA, что обеспечивается (в случае необходимости) добавлением рулевых меток в стэк, чтобы не нарваться на петли. Сильной стороной этого механизма является то, что по факту новый SPT будет соответствовать тому, который IGP пересчитает в случае реальной аварии, отсюда и TI.

Для тех, кто не был знаком с проблематикой, на данном моменте всё должно было стать очевидным. Если в стэке меток содержатся Node SID, которые вышли из строя, или adjacency SID по направлению к ним, TI-LFA не сможет рассчитать резервный путь. Да, от банальной поломки интерфейса защититься возможно, если есть дополнительные, но node protection невозможен.

Существует черновик стандарта (наверное, самая популярная фраза на этом канале), в котором подробно описана проблема и предлагаемый способ её решения (draft-hegde-spring-node-protection-for-sr-te-paths). Суть его состоит в том, чтобы для каждого соседнего LSR по пути LSP в специальной таблице PLR сохранял метки и действия для них от лица этого LSR. То есть необходимо хранить не только свои метки, но ещё и за соседа посчитать и сохранить результат в его контексте меток (здесь нам снова потребуется RFC 5331). А нужно это для того, чтобы по метке, которую сосед использовал бы для передачи трафика, определить next-next-hop LSR. Расписываю я это всё затем, чтобы сделать прозрачный намёк на то, как элегантная и где-то даже простая технология начинает потихоньку обрастать монструозными конструкциями, призванными закрыть её недостатки (и создать новые). А так уж ли плох RSVP-TE?

В Тбилиси проходит очередной ENOG, кому интересно вот ссылка на трансляцию.

SFP DAC кабель в продольном и поперечном разрезах с пояснениями:
https://twitter.com/TubeTimeUS/status/1133904087097851904