Building a Scalable Internet Exchange Point using EVPN with VXLAN
От тех самых IP Infusion, чью NOS на вайтбоксах использует у себя LINX

Продолжение нашумевшего боевика не заставило себя долго ждать

https://blog.apnic.net/2019/03/22/bgp-communities-a-weapon-for-the-internet-part-2/

DAY ONE: CONFIGURING SEGMENT ROUTING WITH JUNOS

Keeping the Balance
Load balancing Demystified

Разбираемся с тем, что такое балансировка нагрузки и какие бывает ее разновидности.

HCIE-R&S V3.0 Training Material (pdf, 1140 страниц)

Prometheus exporter for FFR

https://github.com/tynany/frr_exporter

ARouteServer

A Python tool to automatically build (and test) feature-rich configurations for BGP route servers.

https://github.com/pierky/arouteserver

В EVPN с MPLS dataplane изначально была заложена поддержка репликации BUM за счёт использования P2MP LSP, механизм работы которой был позаимствован из в NG MVPN. Вообще между этими двумя технологиями очень много общего, например, при работе над стандартом EVPN явно использовали такой же подход к описанию route types, как у «старшего брата». Унификация это здорово.

Долгое время многие популярные реализации EVPN поддерживали репликацию BUM только на ingress PE, сейчас же возможность использовать как минимум mLDP есть практически у всех. Однако с ростом эффективности утилизации сетевых каналов появляются и сопутствующие проблемы: P2MP LSP — это состояния на всех промежуточных устройствах, при этом на каждый EVI/BD может требоваться свой отдельный туннель, ещё больше усугубляя ситуацию. К счастью из мира NG MVPN вместе с атрибутом PMSI по наследству досталась и возможность объединять P2MP LSP в один общий aggregated P-tunnel. Но такой подход создаёт уже свои собственные проблемы. Во-первых, процент совпадения egress PE для всех объединямых EVI/BD должен быть относительно высоким (congruence problem — RFC 6513, 6.3.2). Во-вторых, так как P2MP LSP больше не соотносится с EVI/BD, появляется необходимость в рамках общего P-tunnel как-то различать между собой трафик этих EVI/BD. А самое главное, что агрегация P2MP LSP толком никем не поддерживается (хотя это вопрос времени).

Для решения второй проблемы с индентификацией сервиса в рамках общего туннеля в RFC 6513 предлагается на ingress PE выделять метку (upstream label allocation) и сигнализировать её в атрибуте PMSI (в EVPN он передаётся в route type 3), каждый egress PE по метке туннеля находит контекст меток конкретного ingress PE, из которого по PMSI метке понимает, к какому сервису этот BUM трафик относить. Этот способ несёт свои недостатки (да сколько можно?!), масштабами которых нас запугивают в черновике draft-ietf-bess-mvpn-evpn-aggregation-label. Интересный документ, авторы которого предлагают решить описанные ими проблемы с масштабированием при помощи подхода, применяемого в Segment Routing, выделяя общий блок меток для использования всеми ingress PE (концепция SRGB). Вот таким образом SR входит в жизнь EVPN (и заодно NG MVPN), если всё это реализуют, конечно. Мне на память пришёл похожий случай, вот почитайте — draft-swallow-mpls-aggregated-fec (хорошо, хоть протух бесславно), можно найти что-то очень знакомое :)

Хороший отчёт о внедрении IPv6 с экономической точки зрения. Какие драйверы, плюсы/минусы несёт внедрение IPv6 для сетей в зависимости от их типа, размера и скорости роста и других факторов. Какие стратегии внедрения IPv6 выбирают операторы сетей. https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-final-report.pdf

Russ White объясняет на схеме как BIER используется для доставки сетевых данных multicast:
https://rule11.tech/bier-basics/

400G от Arista Networks

Один из первых коммутаторов на чипе Broadcom Tomahawk 3

Datasheet: https://www.arista.com/assets/data/pdf/Datasheets/7060X4-Datasheet.pdf

Видеопрезентация:
https://youtu.be/LHONmUuenyo

Доп инфа про 7060DX и 7060PX:
https://people.ucsc.edu/~warner/Bufs/7060-t3.html

Подробней про чип T3:
https://www.tg-me.com/ntwrkchnnl/659

Новая мода и стиль для современных ДЦ - 32 x 400G в модульном 4RU шасси

Arista 7368X4:
https://www.arista.com/assets/data/pdf/Datasheets/7368X4-Datasheet.pdf

Cisco Nexus 3408-S:
https://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/datasheet-c78-741562.pdf

Edge-Core MINIPACK AS8000:
https://www.edge-core.com/_upload/images/Minipack_DS_R01_20190312.pdf

Juniper на OCP SUMMIT представил свою новую разработку - cRPD

Microsoft продолжает активно развивать свою операционную систему для bare-metal свичей - SONiC (Software for Open Networking in the Cloud)

Ознакомиться с актуальной архитектурой ОС можно тут:
https://github.com/Azure/SONiC/wiki/Architecture

На самом деле очень грустно, когда западный гиперскейл показывает такие крутые штуки как SONiC, а наш гиперскейл на конфах показывает бекапилку конфигов на питоне 😐

Juniper кстати тоже расстраивает - в 2019 году они таки осилили перейти с bsd на linux и внедрить state db.

И state db и linux и даже message bus у конкурентов еще в 2008 году были. А теперь наиболее активные сейлы/евангелисты джуна кричат на каждом углу, что это мол вообще инновация и все остальные вендоры "далеко позади". Ребята, вы серьезно? Вы отставание от конкурентов на 11 (одиннадцать) лет пытаетесь за преемущество выдавать? 😕