В первой части статьи я попытался описать возможности некоторых подходов к балансировке трафика в MPLS домене, идея была в том чтобы показать уникальные требования к аппаратной реализации чипа, которые позволяют достигнуть успеха, в том или ином случае. Вторая часть будет посвящена рассказу об относительно свежем драфте [Multi-path Label Switched Paths Signaled Using RSVP-TE] от Kireeti Kompella, и описанию применения его реализации от Juniper к решению некоторых задач.

Технологии MPLS сегодня стали де-факто стандартом построения сетей операторов связи. Некоторые участники начальных разработок утверждают, что работа была направлена на получение протокола с фиксированной длинной заголовка чтобы упростить процесс принятия решений маршрутизации, однако революционных изменений в этом смысле не произошло, а после после появления аппаратных реализаций коммутационных чипов проблема производительности отошла на второй план. Зато по мере того как стандарт обрастал мышцами, становилось понятно, что применение нескольких меток, названных впоследствии стеком, позволяет взглянуть на MPLS как на технологию с унифицированными методами предоставления и обеспечения сервисов. Так, метки в стеке условно поделили на сервисные и транспортные. Для больших сетей этого оказалось недостаточно и вскоре появилась собственная иерархия транспортных меток. Транзитные маршрутизаторы в общем не обязаны понимать какой именно сервис они передают, их задача в самом общем смысле ограничивается работой с верхней меткой своей иерархии, а что там находится внутри стека совершенно не их забота. Такой подход позволяет транзитным маршруитзаторам передавать трафик сотен тысяч и даже миллионов потоков разных сервисов.

Казалось бы, чего еще желать… правило «разделяй и властвуй» работает безотказно, но вот эффективно разделять как раз не очень то получалось, в том смысле, что трафик хочется балансировать как можно равномернее в рамках ограниченного количества каналов связи силами неторопливых, с точки зрения изменений, аппаратных решений. В статье вы найдете некоторые аспекты разных методов решения этой задачи.

Казалось бы, довольно простой вопрос — техническая поддержка, или как ее еще часто называют, сервис производителя, но насколько же по разному относятся к его покупке разные люди, в зависимости от их должностных обязанностей и роли в компании.

Если коротко, то найти адекватного интегратора и заставить его как следует поработать над решением вашей задачи (т.е. проектом), но ни в коем случае не делать все самим.

Широко известной новостью в узких кругах стало появление в релизе Junos 16.1 механизмов расширенной очередизации на фиксированных 10G портах платформ MX80/MX104.

Как это иногда случается, техническая документация по новым возможностям выходит с некоторой задержкой, даже сейчас разделы посвященные этой теме оставляют ощущение недосказанности. К счастью, коллеги из московского представительства Juniper на конференции Juniper Networks Summit помогли найти ответы, за что им большое спасибо.

Juniper анонсировал новую платформу на новом же супер-пупер чипсете Express. Называется платформа PTX. Есть две модели: показанный на картинке PTX5000 и непоказанный PTX9000, который тоже в два прокрута колеса мышки на экране высотой, но еще и в два раза шире.



Не волнуйтесь, дорогие хабровчане, это не пресс-релиз от лица компании Juniper Networks, призыващий срочно покупать новый продукт. Они со своей рекламой справятся как-нибудь сами. Да и покупать пока нечего: анонсирована не значит продается. Не говоря уже о цене.