Привет. Я Марат Сибгатулин — сетевик в Яндексе, ведущий подкаста linkmeup, автор серии книг «Сети для самых маленьких» и спикер курса Слёрм Сети для DevOps, который мы сделали совместно с linkmeup.
Сегодняшний рассказ будет про несколько органических проблем современных сетевых технологий.
Привет, я Сергей Еланцев, разрабатываю сетевой балансировщик нагрузки в Яндекс.Облаке. Раньше я руководил разработкой L7-балансировщика портала Яндекса — коллеги шутят, что чем бы я ни занимался, получается балансировщик. Я расскажу читателям Хабра, как нужно управлять нагрузкой в облачной платформе, каким мы видим идеальный инструмент достижения этой цели и как движемся к построению этого инструмента.Читать полностью »
В первой части статьи я попытался описать возможности некоторых подходов к балансировке трафика в MPLS домене, идея была в том чтобы показать уникальные требования к аппаратной реализации чипа, которые позволяют достигнуть успеха, в том или ином случае. Вторая часть будет посвящена рассказу об относительно свежем драфте [Multi-path Label Switched Paths Signaled Using RSVP-TE] от Kireeti Kompella, и описанию применения его реализации от Juniper к решению некоторых задач.
Читать полностью »
Технологии MPLS сегодня стали де-факто стандартом построения сетей операторов связи. Некоторые участники начальных разработок утверждают, что работа была направлена на получение протокола с фиксированной длинной заголовка чтобы упростить процесс принятия решений маршрутизации, однако революционных изменений в этом смысле не произошло, а после после появления аппаратных реализаций коммутационных чипов проблема производительности отошла на второй план. Зато по мере того как стандарт обрастал мышцами, становилось понятно, что применение нескольких меток, названных впоследствии стеком, позволяет взглянуть на MPLS как на технологию с унифицированными методами предоставления и обеспечения сервисов. Так, метки в стеке условно поделили на сервисные и транспортные. Для больших сетей этого оказалось недостаточно и вскоре появилась собственная иерархия транспортных меток. Транзитные маршрутизаторы в общем не обязаны понимать какой именно сервис они передают, их задача в самом общем смысле ограничивается работой с верхней меткой своей иерархии, а что там находится внутри стека совершенно не их забота. Такой подход позволяет транзитным маршруитзаторам передавать трафик сотен тысяч и даже миллионов потоков разных сервисов.
Казалось бы, чего еще желать… правило «разделяй и властвуй» работает безотказно, но вот эффективно разделять как раз не очень то получалось, в том смысле, что трафик хочется балансировать как можно равномернее в рамках ограниченного количества каналов связи силами неторопливых, с точки зрения изменений, аппаратных решений. В статье вы найдете некоторые аспекты разных методов решения этой задачи.
Читать полностью »
Вышел на меня заказчик на первый взгляд с нетривиальной задачей «поднять два провайдера и настроить VPN между двумя офисами».
Для таких мелких задач обычно не пишутся ТЗ, а максимум достаточно схемы в Visio.
А вот и сама схема
А вот в чём собственно проблема.
Проблема в том, что на маршрутизаторе R1 три 192.168.0.0/24 сети, а также третья проблема — это то что удалённая сеть также имеет сеть 192.168.0.0/24
Читать полностью »
Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.
Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).
Давайте рассмотрим что же мы можем сделать:
Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов
Читать полностью »
