MPLSWC2019Presentations.zip
413.9 MB
А вот и презентации с прошедшего в Париже MPLS World Congress.
ASR9000 Series Hardware Overview
https://null.53bits.co.uk/index.php?page=asr9000-series-hardware-overview
https://null.53bits.co.uk/index.php?page=asr9000-series-hardware-overview
DO_Ambassadors2019.pdf
6.7 MB
Вышел новый DAY ONE: JUNIPER AMBASSADORS’ COOKBOOK FOR 2019
Прототип 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
YouTube
ONF Connect 18: Implementing the Programmable Service Edge
Небольшая работа "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. Список обработанной литературы впечатляет.
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
https://www.cisco.com/c/m/ru_ru/training-events/cisco-connect/materials.html
Cisco
Cisco — Россия
Cisco является мировым лидером в области информационных технологий и сетей. Мы помогаем компаниям всех размеров использовать новые возможности для связи, общения и совместной работы.
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/
Свежий выпуск подкаста 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
У Juniper Networks в очередной раз упала выручка на 7%.
https://www.lightreading.com/cloud/network/juniper-reports-$1b-revenue-for-1q-2019-down-7--annually/d/d-id/751053
Cлайды с Juniper Networks Benelux TechClub2019
http://emea.juniper.net/TechClubBNLX2019_Presentations
http://emea.juniper.net/TechClubBNLX2019_Presentations
Foundations_of_Modern_Networking_.pdf
25.1 MB
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
jg's Ramblings
The Blind Men and the Elephant
Bufferbloat is responsible for much of the poor performance seen in the Internet today and causes latency (called “lag” by gamers), triggered even by your own routine web browsing and v…
Рецепт красивого сбора и мониторинга 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/
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/
Karneliuk
DC/SP. Part 12/7. Monitoring logs from Docker containers and network functions (Cumulus, Cisco, Arista, Nokia) using Telegraf,…
Hello my friend,
Within the Service Provider Project some time ago we’ve reviewed on of the most popular and robust stack for monitoring virtually anything based on InfluxData Telegraf, InfluxDB and Grafana. That time we’ve used SNMP to collect the information…
Within the Service Provider Project some time ago we’ve reviewed on of the most popular and robust stack for monitoring virtually anything based on InfluxData Telegraf, InfluxDB and Grafana. That time we’ve used SNMP to collect the information…
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
https://www.nextplatform.com/2018/06/20/a-deep-dive-into-ciscos-use-of-merchant-switch-chips
Forwarded from Curious notes
Не смотря на весь хайп, но при этом действительно неплохие возможности, у 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?
Из каждого утюга доносится: 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, кому интересно вот ссылка на трансляцию.
www.enog.org
Live – Original Feed | ENOG
SFP DAC кабель в продольном и поперечном разрезах с пояснениями:
https://twitter.com/TubeTimeUS/status/1133904087097851904
https://twitter.com/TubeTimeUS/status/1133904087097851904