Новые фишки для управления сетями в Ansible 2.9
https://www.ansible.com/blog/network-features-coming-soon-in-ansible-engine-2.9
https://www.ansible.com/blog/network-features-coming-soon-in-ansible-engine-2.9
Forwarded from TT — Terrible Telco (Дмитрий Шемонаев)
Всем привет.
Расширяем наш саппорт. У нас круто и движ.
Описание вакансии:
https://qrator.net/ru/company/vacancy/injener_tehnicheskoy_podderjki
За подробностями можно написать @anna_tyshkevich или @shemonaev
Расширяем наш саппорт. У нас круто и движ.
Описание вакансии:
https://qrator.net/ru/company/vacancy/injener_tehnicheskoy_podderjki
За подробностями можно написать @anna_tyshkevich или @shemonaev
Network Warrior
Полное погружение в Juniper Packet Forwarding Engine (PFE). Lookup memory, buffer memory, tcam, sram, rldram, j-cell и вот это все https://forums.juniper.net/t5/Routing/An-Informal-Guide-to-the-Engines-of-Packet-Forwarding/ta-p/401192
Еще более полное погружение в Juniper PFE, а конкретно в LU-chip
https://null.53bits.co.uk/index.php?page=mx-trio-pfe-lu-deep-dive
https://null.53bits.co.uk/index.php?page=mx-trio-pfe-lu-deep-dive
Internet in VRF vs Internet in GRT. Небольшая таблица с плюсами и минусами обоих решений, которая, возможно, поможет при строительстве новой сети, миграции старой. https://ntwrk.today/2019/10/16/internet-in-vrf.html
SANOG34-Tutorials-spring-for-service-providers-v1.3.pdf
8.7 MB
Juniper. SPRING FOR SERVICE PROVIDER NETWORKS
Resilient Interdomain Traffic Exchange:
BGP Security and DDoS Mitigation
Вышел отличный документ от NIST (National Institute of Standards and Technology. U.S. Department of Commerce). В нем описаны уязвимости control/data plane и методы борьбы с ними. В целом ничего прямо нового, кроме драфта по Enhanced Feasible-Path uRPF(https://tools.ietf.org/html/draft-ietf-opsec-urpf-improvements-04), но все собрано в одном месте.
Пока ждем EFP-uRPF, есть надежда, что если маленькая часть людей прочтет и включит хотя бы uRPF strict mode в сторону своих single-homed customers и uRPF loose mode в сторону multihomed customers - мир станет чуточку лучше.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft2.pdf
BGP Security and DDoS Mitigation
Вышел отличный документ от NIST (National Institute of Standards and Technology. U.S. Department of Commerce). В нем описаны уязвимости control/data plane и методы борьбы с ними. В целом ничего прямо нового, кроме драфта по Enhanced Feasible-Path uRPF(https://tools.ietf.org/html/draft-ietf-opsec-urpf-improvements-04), но все собрано в одном месте.
Пока ждем EFP-uRPF, есть надежда, что если маленькая часть людей прочтет и включит хотя бы uRPF strict mode в сторону своих single-homed customers и uRPF loose mode в сторону multihomed customers - мир станет чуточку лучше.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft2.pdf
IX-API An Application Programming Interface for Interconnection Services.
IXP-ребята решили скооперироваться и разработать REST API для взаимодействия с кастомерами : провижининг L2 сервисов, регистрация MAC адреса клиентского роутера, конфигурация сессии с RS. В roadmap : статистика, мониторинг и даже управление физическими коннектами (наверно отсылка к path robot от DECIX).
Приглашают участвовать в разработке не только непосредственно IXP, но и клиентов.
Сайт: https://ix-api.net/
Видео презентации: https://ripe79.ripe.net/archives/video/295
Слайды: https://ripe79.ripe.net/wp-content/uploads/presentations/136-RIPE79_TK_IX-API_Introduction_Final.pdf
IXP-ребята решили скооперироваться и разработать REST API для взаимодействия с кастомерами : провижининг L2 сервисов, регистрация MAC адреса клиентского роутера, конфигурация сессии с RS. В roadmap : статистика, мониторинг и даже управление физическими коннектами (наверно отсылка к path robot от DECIX).
Приглашают участвовать в разработке не только непосредственно IXP, но и клиентов.
Сайт: https://ix-api.net/
Видео презентации: https://ripe79.ripe.net/archives/video/295
Слайды: https://ripe79.ripe.net/wp-content/uploads/presentations/136-RIPE79_TK_IX-API_Introduction_Final.pdf
Internet Clouds are (also) Unpredictable! Презентация и видео статьи ранее вышедшей на сайте RIPE про довольно агрессивный TE внутри AWS облака, который может заставить пользователей перебирать Source Port для получения лучшего RTT.
Статья: https://labs.ripe.net/Members/marco_chiesa/internet-clouds-are-also-unpredictable
Презентация: https://ripe79.ripe.net/wp-content/uploads/presentations/53-aws-te-submitted.pdf
Видео: https://ripe79.ripe.net/archives/video/190
Статья: https://labs.ripe.net/Members/marco_chiesa/internet-clouds-are-also-unpredictable
Презентация: https://ripe79.ripe.net/wp-content/uploads/presentations/53-aws-te-submitted.pdf
Видео: https://ripe79.ripe.net/archives/video/190
RIPE Labs
Internet Clouds are (also) Unpredictable: A Study on the Effects of Recent Traffic Engineering Trends In Cloud Provider Networks
How does the largest cloud provider worldwide perform Traffic-Engineering? What are the implications for the geo-distributed applications running in the cloud? We explored these and more questions through a comprehensive set of measurements across the Amazon…
Прошлое, настоящее и будущее PCI-Express https://www.nextplatform.com/2019/10/15/pci-express-steps-up-to-the-bandwidth-challenge/
The Next Platform
PCI-Express Steps Up To The Bandwidth Challenge
Moore’s Law might be slowing down CPU compute capacity increases in recent years, but the innovation has been coming at a steady drumbeat for the
О проблемах SRv6 и преимуществах SRv6+ от одного из авторов драфтов SRv6+. Порой спорно, но заслуживает внимания. https://www.linkedin.com/pulse/srv6-followup-article-andrew-alston
LinkedIn
SRv6+ - A followup article
So, following my post a few months ago about why we wanted SRv6+ - and having become fairly actively involved in the space, including joining the co-authorship of the CRH, SRv6+ and CRH BGP Signalling drafts, I thought it was time for a followup article to…
Forwarded from Curious notes
Все знают про такую вещь как microloops. Долгое время я думал, что использование IP FRR технологий полностью исключает возможность их возникновения, как минимум, для префиксов, которые выбранный repair механизм «покрывает». Логика, которой я руководствовался, заключается в следующем: если для префикса есть запасной путь, то PLR рассчитывает его таким образом, чтобы он не проходил через маршрутизатор, для которого мы являемся next-hop, что и является условием образования, как минимум, локальных петель. Но недавно я наткнулся на кое-что, что заставило меня сомневаться в правильности моего понимания вопроса, и, как оказалось, не зря.
В RFC 8333, являющийся одним из наиболее свежих документов на эту тему, подробно описывается, почему микропетли могут быть проблемой даже в сетях с IP FRR (в том числе и с RLFA). В корне неверно рассматривать local repair как часть глобального процесса схождения сети, хотя очень удобно думать: «Пока там что-то посчитается и придёт к общей картине, FRR поработает и спасёт отца русской демократии». На самом деле, repair – это независимый, можно даже сказать – несвязанный, процесс. Как только PLR переводит трафик в резервный интерфейс/туннель, он запускает процесс (а может даже и раньше) расчёта своей LSDB и, несмотря на то что он уже отправил LSA/LSP соседям, этот процесс имеет все шансы завершиться быстрее соседских. В случае наступления этого события PLR переводит трафик обратно на т. н. «post convergence path», имеющий все шансы запетлять между нами и соседом или где подальше.
Ещё один важный момент, что в LFA резервный путь может отличаться от того, что будет далее посчитан IGP, в RLFA он всегда отличается, так как в нормальной ситуации трафик не передаётся в туннеле до PQ-устройства (как именно строится сам туннель – другой вопрос), и как только SPF пересчитает дерево, обновив RIB/FIB, трафик перейдёт на post convergence path, который может быть скомпрометирован временной петлёй. В TI-LFA резервный путь рассчитывается таким образом, чтобы он всегда совпадал с post convergence path, но это всё равно не исключает того, что после локального пересчёта SPF и переключения пути трафик может временно покружиться. Даже с SR приходится дополнительно активировать какие-нибудь механизмы по защите от микропетель.
Другой «подводный» камень заключается в том, что FRR технологии срабатывают только в случае отказа элемента сети, в то время как пересчёт топологи может вызывать и появление новых элементов, что тоже является благодатной пищей для временных петель.
Помимо RFC 8333 на эту тему стоит почитать и другие документы, например, в RFC 5715 описывается проблематика и способы борьбы с микропетлями. Можно узнать, что помимо популярного oFIB есть множество других механизмов и подходов к проблеме, я вот не знал. Правда, от большей части из них уже не очень приятно пахнет.
В RFC 8333, являющийся одним из наиболее свежих документов на эту тему, подробно описывается, почему микропетли могут быть проблемой даже в сетях с IP FRR (в том числе и с RLFA). В корне неверно рассматривать local repair как часть глобального процесса схождения сети, хотя очень удобно думать: «Пока там что-то посчитается и придёт к общей картине, FRR поработает и спасёт отца русской демократии». На самом деле, repair – это независимый, можно даже сказать – несвязанный, процесс. Как только PLR переводит трафик в резервный интерфейс/туннель, он запускает процесс (а может даже и раньше) расчёта своей LSDB и, несмотря на то что он уже отправил LSA/LSP соседям, этот процесс имеет все шансы завершиться быстрее соседских. В случае наступления этого события PLR переводит трафик обратно на т. н. «post convergence path», имеющий все шансы запетлять между нами и соседом или где подальше.
Ещё один важный момент, что в LFA резервный путь может отличаться от того, что будет далее посчитан IGP, в RLFA он всегда отличается, так как в нормальной ситуации трафик не передаётся в туннеле до PQ-устройства (как именно строится сам туннель – другой вопрос), и как только SPF пересчитает дерево, обновив RIB/FIB, трафик перейдёт на post convergence path, который может быть скомпрометирован временной петлёй. В TI-LFA резервный путь рассчитывается таким образом, чтобы он всегда совпадал с post convergence path, но это всё равно не исключает того, что после локального пересчёта SPF и переключения пути трафик может временно покружиться. Даже с SR приходится дополнительно активировать какие-нибудь механизмы по защите от микропетель.
Другой «подводный» камень заключается в том, что FRR технологии срабатывают только в случае отказа элемента сети, в то время как пересчёт топологи может вызывать и появление новых элементов, что тоже является благодатной пищей для временных петель.
Помимо RFC 8333 на эту тему стоит почитать и другие документы, например, в RFC 5715 описывается проблематика и способы борьбы с микропетлями. Можно узнать, что помимо популярного oFIB есть множество других механизмов и подходов к проблеме, я вот не знал. Правда, от большей части из них уже не очень приятно пахнет.
Forwarded from Yandex.NextHop
Yandex_NextHop_2019.zip
191.6 MB
А вот и долгожданные презентации с недавно прошедшей конференции Yandex NextHop 2019
Преимущества_перехода_на_новую_серию.pdf
997.9 KB
Cisco выкатила русскоязычный FAQ "Преимущества перехода на новую серию коммутаторов Cisco Catalyst 9k". Документ включает в том числе и очередную попытку рассказать чем хорош и удобен новый способ лицензирования DNA.
Презентации с Juniper NTWRK Summit Moscow 2019.
https://content.juniper.net/jsummit-moscow-q419-presentations?utm_source=thx_eml
https://content.juniper.net/jsummit-moscow-q419-presentations?utm_source=thx_eml
ПМО Juniper summit 2019-fin.pdf
3.2 MB
Опыт построения сети Правительства Московской области
Презентация с Juniper Summit Moscow 2019 от нашего друга Ильи Сомова @somovis с авторскими комментариями и пояснениями.
Презентация с Juniper Summit Moscow 2019 от нашего друга Ильи Сомова @somovis с авторскими комментариями и пояснениями.
Guide to Security in SDN and NFV.pdf
6.8 MB
Guide to Security in SDN and NFV
2017
2017
ComputerNetworks.pdf
7 MB
An Introduction to Computer Networks
Книга используется для обучения компьютерным сетям в Loyola University в Chicago.
Peter L Dordal
2019
Книга используется для обучения компьютерным сетям в Loyola University в Chicago.
Peter L Dordal
2019