Русский
Русский
English
Статистика
Реклама

Pim

Из песочницы Сравнение 3 бесплатных решений для управления информацией о товарах (PIM систем)

05.11.2020 00:13:01 | Автор: admin
image

На рынке доступно множество коммерческих решений для управления информацией о товарах (PIM). И есть 3 бесплатных решения с открытым исходным кодом: Akeneo, Pimcore и OpenPIM, которые вы можете использовать для внедрения системы PIM в своей компании. Я собираюсь сравнить эти 3 решения друг с другом.



1. Akeneo


image

У Akeneo есть бесплатная версия и коммерческая корпоративная версия. Вы можете увидеть сравнение этих версий на https://www.akeneo.com/compare-editions/.

В этом обзоре мы будем использовать только бесплатную версию, потому что мы сосредоточены только на бесплатных решениях PIM.

1.1. Модель данных

Akeneo использует объекты Product как сущности для хранения информации о продуктах. У продуктов есть значения атрибутов, которые связаны с соответствующим атрибутом. Поддерживаются различные типы атрибутов. Вы можете легко создать новый атрибут в пользовательском интерфейсе без написания кода. Подробности вы можете найти здесь.

Для PIM систем очень важно уметь поддерживать различный набор атрибутов в зависимости от типа продукта, например, MP3-плеер имеет другой набор атрибутов, чем футболка.

Akeneo использует для этого объекты Families. Таким образом, каждое семейство определяет набор атрибутов, необходимых для этого типа продукта, и каждый продукт имеет ссылку на свое собственное семейство. Товар может принадлежать только к одному семейству.

Атрибуты в Akeneo могут иметь разные значения для разных языков и каналов. Поддержка атрибутов сделана вполне хорошо и позволяет решать различные бизнес задачи.

1.2. Иерархии

Иерархия, к которой может принадлежать продукт, в Akeneo называется категориями. Вы можете иметь сколько угодно иерархий. Но категории в Akeneo очень простые. Вы не можете назначить атрибут для категории, а также нельзя ограничить, может ли продукт быть связан только с одним или несколькими узлами категорий и т.д.

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

1.3. Пользовательские объекты

Часто в PIM требуется хранить не только информацию о товаре, но и некоторые другие объекты, например Бренд или Магазин (где этот товар находится) и т.д. Эти дополнительные объекты могут иметь свои собственные атрибуты.

У Akeneo нет поддержки пользовательских объектов в бесплатной версии. Эта функциональность поддерживается только в коммерческой версии. Опять же, вы можете создать собственное расширение и получить эту функциональность, но для этого потребуются дополнительные затраты.

1.4. Зависимости

Отношения используются в PIM, чтобы указать, что данные имеют некоторые зависимости. Например, что этот товар можно заменить другим, или товар можно продать вместе с другим и т. д.

Akeneo поддерживает только отношения между продуктами (поскольку пользовательские объекты не поддерживаются). Вы можете определить Association Type и использовать его для связи между продуктами.

Но опять же, эти ассоциации очень простые. Например, вы не можете определить атрибут для этой ассоциации, хотя это может быть очень полезно. Например, это часто используется в наборах (или аналогичных функциях) для обозначения порядка продуктов в нем.

1.5. Варианты

Варианты представляют собой один и тот же товар, но с некоторыми разными атрибутами (когда все остальные атрибуты одинаковы). Например, у вас может быть футболка разных цветов и размеров.

Akeneo поддерживает варианты, вы можете создать Family Variant, который определяет, какие атрибуты отличаются https://help.akeneo.com/pim/serenity/articles/manage-your-families.html#manage-family-variants. Также у Akeneo хорошая поддержка вариантов в интерфейсе пользователя.

Ограничение состоит в том, что для различных продуктов можно контролировать только 3 уровня вариаций.

1.6. Активы

Активы это изображения, видео или файлы, связанные с товарами. Это очень важная информация, которая обычно хранится в системах PIM.

Бесплатная версия Akeneo имеет очень ограниченную поддержку файлов. У вас может быть только поле, куда вы можете поместить изображение или файл. Если вам нужно больше изображений, вам нужно создать больше полей. Вы не можете прикреплять к ним атрибуты, и у вас не может быть для них никакой структуры.

1.7. Импорт/Экспорт

Akeneo имеет возможность импортировать и экспортировать данные из файлов CSV, Excel и XML. Но вы не можете сопоставить столбцы вашего файла с моделью данных Akeneo. В Akeneo есть набор предопределенных конфигураций импорта/экспорта, поэтому вы должны указать правильные имена столбцов для загрузки или экспорта данных. Также вы не можете трансформировать данные на лету, что часто бывает необходимо при интеграции с различными источниками.

Таким образом, возможности Akeneo по импорту и экспорту весьма ограничены.

1.8. Полнота продукта и качество данных

Akeneo имеет хорошую поддержку для определения полноты продукта (это часть качества данных товаров). Вы можете определить, какие атрибуты требуются для каждого типа продукта (семейства) и для каждого канала. Также UI имеет хорошую поддержку для отображения этой информации.

Akeneo поддерживает некоторые аспекты качества данных товаров, например, тип атрибута предотвращает некоторые ошибки пользователя, определение полнота продукта также хорошо. Но опять же, поддержка настраиваемой проверки качества очень ограничена. Вы должны программировать на низком уровне, если хотите определить свою собственную логику качества (а это бывает очень часто в реальном бизнесе).

В коммерческой версии есть поддержка механизма правил, что хорошо, но для бесплатной версии такой поддержки нет.

1.9. Пользовательская логика и расширение интерфейса пользователя

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

Akeneo поддерживает это только с помощью низкоуровневого PHP-кода. Вы можете определить свою собственную логику и формы, но это требует знаний фреймворка PHP и занимает много времени.

1.10. Заключение

Бесплатная версия Akeneo имеет довольно большие ограничения, которые могут помешать ее использованию в реальном бизнесе. Ограниченная работа с файлами или отсутствие пользовательских объектов и возможности легко определять настраиваемую логику может помешать многим компаниям использовать бесплатную версию. Поддержка иерархий и отношений также слишком просты, чтобы удовлетворить все потребности бизнеса.

В коммерческой версии Akeneo большинство этих проблем решено. Кроме того, у Akeneo есть хорошее сообщество и сеть партнеров для поддержки. Поэтому я бы рекомендовал использовать коммерческую версию Akeneo, если бизнес готов за нее платить (это недешево). А если вы ищете бесплатное решение PIM, я бы не рекомендовал использовать Akeneo.

2. Pimcore


image

Pimcore это не только решение PIM, но и MDM. Он также имеет возможности DAM (Asset Management). Pimcore также позиционирует себя как платформу цифровой коммерции и клиентских данных, поэтому имеет множество функций. В нашем обзоре мы будем рассматривать только PIM.

У Pimcore также есть бесплатная и коммерческая версии https://pimcore.com/en/platform/subscription. Но функциональность PIM и DAM, на которой мы фокусируемся, существует во всех редакциях.

2.1. Модель данных

Pimcore имеет все необходимые возможности для определения атрибутов, связанных с товарами. Для этого они используют классы объектов. Более того, вы определяете не только сами атрибуты, но и структуру пользовательского интерфейса, как они будут отображаться.

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

Единственная потенциальная проблема, которую я вижу здесь, заключается в том, что система генерирует классы PHP для каждого класса объектов, который вы создаете, поэтому у нас есть реальный PHP-код, стоящий за всем этим пользовательским интерфейсом, и иногда вам необходимо пользоваться подобной информацией в пользовательском интерфейсе, например задавать имя класса PHP или Родительский класс. Поэтому, если вы далеки от программирования, то вам может быть сложно определить модель данных.

2.2. Иерархии

Поскольку классы объектов используются системой везде, вы также можете использовать их и для построения иерархий. Это более гибкое решение, чем Akeneo. Вы можете определить свои структуры в виде классов объектов, как вы хотите, а затем использовать отношения, чтобы связать их с другими объектами.

2.3. Пользовательские объекты

Опять же, классы объектов могут использоваться для представления любых данных, а не только товаров или иерархии. Вы можете определить свои собственные классы объектов для любого типа данных, которые вы хотите хранить в PIM, таких как бренды, магазины и т.д. Вы можете прикрепить к ним необходимые атрибуты и определить пользовательский интерфейс, чтобы отображать их, как обычные продукты.

Так что и в этой области у Pimcore возможностей больше, чем у Akeneo.

2.4. Зависимости

Вы можете определить различные типы отношений между любыми объектами в системе https://pimcore.com/docs/pimcore/current/Development_Documentation/Objects/Object_Classes/Data_Types/Relation_Types.html.

Это позволяет вам создавать необходимые логические связи между вашими данными. Единственный недостаток, который я вижу, это невозможность создания атрибутов для этих зависимостей.

2.5. Варианты

Pimcore имеет встроенную поддержку вариантов. И специализированный интерфейс для них. Я не нашел никаких проблем с этой функциональностью.

2.6. Активы

Pimcore позиционирует себя как полнофункциональное DAM-решение (помимо PIM и других решений). Так что в этой области он может даже больше, чем нужно для PIM.

2.7. Импорт/Экспорт

Возможности Pimcore по импорту/экспорту также ограничены. Эта поддержка лучше, чем у Akeneo, потому что вы можете сопоставить данные столбца CSV или XSL с классами объектов, но это сопоставление очень простое. Вы не можете использовать преобразование и делать какие-либо вычисления на лету.

Форматы XML или JSON напрямую не поддерживаются, это тоже минус.

2.8. Полнота продукта и качество данных

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

В целом, Pimcore имеет хорошую поддержку качества данных. У вас есть возможности и для определения типов полей, и для использования вычисляемых полей для дополнительной проверки и использования workflows для определения вашего процесса. У вас также есть возможности отчетности и дашбордов, которые помогут вам визуализировать эти данные.

2.9. Пользовательская логика и расширение интерфейса пользователя

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

2.10. Заключение

Pimcore большое решение, и не только для PIM. У него больше функций, чем у бесплатной версии Akeneo, но вам придется приложить гораздо больше усилий для реализации проекта, потому что система довольно сложна в изучении и настройке.

Я бы не рекомендовал Pimcore для малого бизнеса из-за его сложности и использования большого количества PHP под капотом. Pimcore ваш выбор, если вы средняя или крупная компания, которая ищет комплексное решение для PIM, DAM, электронной коммерции, MDM и CDP. Кроме того, вы должны помнить, что вам нужны ресурсы с хорошим знанием PHP для реализации своего проекта, если вы хотите реализовать его самостоятельно.

3. OpenPIM, англоязычная версия


image

OpenPIM полностью бесплатное решение. У него нет коммерческой версии, но при необходимости вы можете получить коммерческую поддержку.

3.1. Модель данных

OpenPIM имеет широкие возможности для определения модели данных, схожие с Pimcore. Вы можете определить свой тип и привязать к нему необходимые атрибуты.

Система имеет множество различных типов атрибутов, которые вы можете использовать. Наследование данных напрямую не поддерживается, но может быть легко реализовано с помощью Действий https://openpim.ru/docs/admin/guide/03_Actions.html.

3.2. Иерархии

OpenPIM использует тот же подход, что и Pimcore. Вы можете определить свои собственные типы и использовать их как иерархии (в дополнение к типам, которые используются для продуктов). Затем вы можете использовать отношения, чтобы связать структуру с продуктом или любыми другими данными.

Когда пользователь работает со структурами в Pimcore или Akeneo, он может создавать их по своему усмотрению без какого-либо контроля. Если вы хотите ограничить, какие уровни и как будут создаваться, вам придется использовать собственный PHP-код. У OpenPIM здесь больше возможностей, вы можете определить ограничения с помощью конфигурации без какого-либо программирования.

3.3. Пользовательские объекты

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

Хранение дополнительной информации важный аспект всех PIM систем и OpenPIM имеет всю необходимую функциональность для этого.

3.4. Зависимости

Зависимости используются для логической связи ваших данных детали в документации. Но здесь вы также можете назначить атрибуты и зависимостям, это больше, чем могут сделать Akeneo или Pimcore.
Вы также можете ограничить количество таких зависимостей, что позволяет моделировать отношения один к одному, один ко многим и многие ко многим.

3.5. Варианты

OpenPIM не имеет встроенной поддержки вариантов. Их можно легко смоделировать в модели данных, используя типы и отношения. Таким образом, вы можете легко сохранить эту информацию, но нет специального интерфейса пользователя для вариантов, поэтому вам придется использовать обычный интерфейс для работы с ними. Это менее удобно, чем у Akeneo или Pimcore.

3.6. Активы

Бесплатная версия Akeneo не имеет хорошей поддержки активов, Pimcore это полнофункциональный DAM, поэтому он поддерживает даже больше, чем необходимо. OpenPIM стоит посередине. Он имеет поддержку активов из коробки, поэтому вы можете загружать и связывать файлы и изображения с любым объектом, вы можете создавать структуры для своих активов и добавлять для них необходимые атрибуты. Но вы не можете генерировать файлы производные от существующих (например изображения с другим разрешением или форматом) как в системах DAM. Обычно, для PIM систем этого достаточно, но Pimcore, конечно, имеет больше возможностей в этой области.

3.7. Импорт/Экспорт

OpenPIM имеет отличную поддержку импорта и экспорта, поскольку использует полнофункциональный бесплатный инструмент ETL Talend. Подробности смотрите на https://openpim.ru/docs/admin/guide/02_ImportExport.html.

Таким образом, вы можете импортировать данные из любых источников: CSV, Excel, XML, текстовые файлы, базы данных, веб-службы и т.д. И вы также можете экспортировать данные во все эти источники.

3.8. Полнота продукта и качество данных

Так же, как и в Pimcore OpenPIM не имеет готовой функциональности полноты продукта, но это легко реализовать через Действия. Это потребует некоторых навыков программирования, но не настолько, насколько это необходимо для Pimcore, потому что здесь вы можете задать небольшую логику на javascript, которая будет выполняться при некоторых событиях, и это позволит вам определить логику полноты продукта.

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

Это лучшая поддержка импорта/экспорта из всех трех решений.

3.9. Пользовательская логика и расширение интерфейса пользователя

Как я уже писал, основная возможность определять настраиваемую логику это Действия. Это небольшой код javascript, который может выполняться при наступлении некоторых событий, таких как создание или сохранение данных и других. Вам по-прежнему нужны знания в области программирования, но это намного проще, чем писать собственный PHP-код. В результате вы можете создать свою собственную логику с меньшими затратами времени и усилий.

Недостатком является то, что вы не можете определить свой собственный пользовательский интерфейс, если вам это нужно. Вы можете создать только кнопку, которая будет выполнять некоторые предопределенные действия. Это может быть достаточно для некоторых случаев, но конечно не для всех.

3.10. Заключение

Я бы порекомендовал OpenPIM малым и средним компаниям, которые хотят внедрить PIM-решение самостоятельно, не платя дополнительных денег компаниям-партнерам за помощь в этом процессе.

Его легко изучить и использовать. У него есть некоторые ограничения, такие как невозможность определить настраиваемый пользовательский интерфейс, но в большинстве случаев он покрывает все потребности для реализации PIM системы.

OpenPIM не очень подходит для крупных компаний, потому что в нем отсутствуют некоторые функции, которые требуются таким предприятиям, такие как workflows, порталы поставщиков и т.д., Но он хорош для малого и среднего бизнеса.
Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 2 Profile 1)

22.11.2020 14:12:21 | Автор: admin

В прошлой статье мы познакомились с Вами с исторически первым способом организации построения multicast VPN с помощью технологий PIM и mGRE (Часть 1, Profile 0).


На сегодняшний день существуют альтернативы запуску P-PIM в опорной сети. В частности, для организации многоадресных деревьев можно использовать протокол mLDP. Разберемся как он работает. Но прежде вспомним основные концепции LDP.


  • LDP пиры находят друг друга посредством рассылки Hello сообщений на адрес 224.0.0.2. В рамках Hello передается параметр transport address (который, по-умолчанию в Cisco IOS совпадает с IP адресом LDP router-id)
  • Маршрутизаторы устанавливают ТСР сессию и в рамках неё обмениваются метками для FEC (читай IP префиксов из таблицы маршрутизации)
  • Результат обмена однонаправленный LSP типа Point-to-Point.


  • Помимо этого, пиры в рамках ТСР сессии обмениваются сообщениями типа Initialization, внутри которых передается информация о поддерживаемых возможностях (Capabilities). За обмен информацией отвечают Capabilities TLV.
    • Т.е. обмениваться можно не только информацией об P2P LSP, но и ещё чем-то ...

Вся соль mLDP в том, что для этого протокола FEC представляет собой не какой-то один конкретный префикс, а скорее некую комбинацию из четырёх элементов:


  • Тип дерева
  • Адресное семейство (IPv4/IPv6)
  • IP адрес корневого устройства
  • Корневое устройство заранее определенный коммутатор, в котором начинается mLDP LSP
  • Некое дополнительно значение, в оригиналье именуемое Opaque Value.
    • Используется для обозначения конкретного дерева (читай C-VRF) внутри MPLS инфраструктуры.

Всего для mLDP определено три различных FEC:


  • P2MP FEC (тип дерева = 0x06)
  • MP2MP Upstream FEC (тип дерева = 0x07)
  • MP2MP Downstream FEC (тип дерева = 0x08)

Дерево P2MP характеризуется тем, что только одно устройство (корневое) может передавать трафик. Все остальные участники дерева используются для передачи трафика в сторону заинтересованных получателей. Т.е. Дерево является однонаправленным. LSP типа P2MP визуально можно представить себе следующим образом:



Дерево MP2MP характеризуется тем, что любой заинтересованный маршрутизатор может передавать трафик (равно, как и получать его). При этом трафик всегда бежит в одном из двух направлений: либо по направлению к корневому устройству, либо от него. LSP типа MP2MP визуально можно представить себе следующим образом:



Теперь попробуем разобраться с тем, как именно строится MP2MP LSP в mLDP (P2MP нам будет интересен в следующих статьях цикла).


Построение MP2MP LSP


Точно также как в обычном unicast LSP, направление сигнализации (распространение меток) противоположно направлению следованию трафика.


Весь процесс сигнализации можно разделить на два этапа (очень похожих на процесс построения многоадресного дерева в PIM ASM через точку рандеву):


  • Downstream сигнализация
    • РЕ распространяют метки в сторону корневого маршрутизатора
    • Согласно распространённым меткам, корневой маршрутизатор передаёт трафик в сторону РЕ
  • Upstream сигнализация
    • Корневой маршрутизатор распространяет метки в сторону РЕ
    • Согласно распространённым меткам, РЕ передаёт трафик в сторону корневого маршрутизатора


Как видно, корневой маршрутизатор является центральной точки сети, через который проходит как Downstream, так и Upstream трафик. Технически им может быть любое устройство сети (как Р, так и РЕ). При этом (насколько мне известно) не существует какого-либо динамического протокола выбора корневого маршрутизатора, поэтому требуется ручная конфигурация на всех РЕ (и только на них).


Рассмотрим вариант замены ранее рассмотренного метода построения Default MDT через BGP ipv4 MDT на mLDP на следующей топологии:



В качестве корневого маршрутизатора будем использовать R8.


Проведем базовую преднастройку (подразумевается, что сделаны все настройки из 1-ой части статьи):


  • Отключим на всех маршрутизаторах протокол PIM:
    interface Gi2.Xno ip pim sparse-mode
    
  • адресное семейство BGP MDT (на РЕ):
    router bgp 65001no address-family ipv4 mdt
    
  • и адрес рассылки MDT
    ip vrf C-ONEno mdt default 239.1.1.1
    

Для полной настройки FEC нам остается ввести IP адрес корневого маршрутизатора и Opaque Value. Начнём с РЕ1:


PE1(config)#mpls mldp logging notificationsPE1(config)#!PE1(config)#ip vrf C-ONEPE1(config-vrf)# vpn id 65001:1PE1(config-vrf)# mdt default mpls mldp 8.8.8.8PE1(config-vrf)#*Nov 21 22:41:03.703: %MLDP-5-ADD_BRANCH: [mdt 65001:1 0] Root: 8.8.8.8, Add MP2MP branch MDT(Lspvif0) remote label , local label no_label*Nov 21 22:41:03.742: MLDP: Reevaluating peers for nhop: 10.1.5.5PE1(config-vrf)#*Nov 21 22:41:04.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to upPE1(config-vrf)#*Nov 21 22:41:05.840: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0PE1(config-vrf)#

PE1 создаёт новый интерфейс Lspvif0 (LSP virtual interface, ничто иное как новый PMSI) для MDT с Opaque Value = [65001:1 0] и запускает на нём PIM в рамках C-VRF.


Прим. Opaque Value состоит из двух частей: vpn id и некоторого дополнительного индекса. Если индекс равен нулю, то это указание на использование Default MDT.


Проверим некоторые параметры вновь созданного интерфейса:


PE1#show ip interface Lspvif0Lspvif0 is up, line protocol is up  Interface is unnumbered. Using address of Loopback0 (1.1.1.1)  Multicast reserved groups joined: 224.0.0.1 224.0.0.2 224.0.0.22 224.0.0.13  VPN Routing/Forwarding "C-ONE"

PE1#show ip pim vrf C-ONE interface Address          Interface                Ver/   Nbr    Query  DR         DR                                          Mode   Count  Intvl  Prior172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.151.1.1.1          Lspvif0                  v2/S   0      30     1          1.1.1.1

Посмотрим базу данных по меткам:


PE1#show mpls mldp neighbors  MLDP peer ID    : 5.5.5.5:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 1  Upstream count : 1  Branch count   : 0  Path count     : 1  Path(s)        : 10.1.5.5          LDP GigabitEthernet2.15  Nhop count     : 1  Nhop list      : 10.1.5.5 

PE1#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 5 (RNR LSM ID: 6)   Type: MP2MP   Uptime : 00:07:53  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  RNR active LSP     : (this entry)  Upstream client(s) :    5.5.5.5:0    [Active]      Expires        : Never         Path Set ID  : 6      Out Label (U)  : 1013          Interface    : GigabitEthernet2.15*      Local Label (D): 10017         Next Hop     : 10.1.5.5  Replication client(s): >   MDT  (VRF C-ONE)      Uptime         : 00:07:53      Path Set ID  : 7      Interface      : Lspvif0       RPF-ID       : *

На РЕ1 присутствует Upstream сосед, которому была передана метка 10017. Трафик, который будет передавать от РЕ1 в сторону R8 получит метку 1013 от Р1.


На Р1 соседей гораздо больше (согласно топологии шестеро):


P1#show mpls mldp neighbors  MLDP peer ID    : 4.4.4.4:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 1  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.4.5.4          LDP GigabitEthernet2.45  Nhop count     : 0 MLDP peer ID    : 1.1.1.1:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 2  Upstream count : 0  Branch count   : 1  Path count     : 1  Path(s)        : 10.1.5.1          LDP GigabitEthernet2.15  Nhop count     : 0 MLDP peer ID    : 8.8.8.8:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 3  Upstream count : 1  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.8.8          LDP GigabitEthernet2.58  Nhop count     : 1  Nhop list      : 10.5.8.8  MLDP peer ID    : 6.6.6.6:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 4  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.6.6          LDP GigabitEthernet2.56  Nhop count     : 0 MLDP peer ID    : 7.7.7.7:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 5  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.7.7          LDP GigabitEthernet2.57  Nhop count     : 0 MLDP peer ID    : 9.9.9.9:0, uptime 1w5d Up,   Target Adj     : No  Session hndl   : 6  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.9.9          LDP GigabitEthernet2.59  Nhop count     : 0

P1#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 3   Type: MP2MP   Uptime : 00:13:23  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    8.8.8.8:0    [Active]      Expires        : Never         Path Set ID  : 9      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*      Local Label (D): 1014          Next Hop     : 10.5.8.8  Replication client(s):     1.1.1.1:0       Uptime         : 00:13:23      Path Set ID  : A      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*      Local label (U): 1013          Next Hop     : 10.1.5.1

Обратите внимание на тот факт, что на Р1 C-VRF не настроен, однако маршрутизатор понимает MP2MP дерево согласно по-умолчанию включённому функционалу recursive fec.


На Р1 есть один Upstream сосед (тот, через которого можно добраться на корня дерева) и один Downstream сосед. Для передачи данных в сторону РЕ1, как и ожидалось, используется метка 10017. При получении mLDP метки 10017, Р1 генерирует метку 1014 и отправляет её в сторону Upstream соседа.



Здесь можно сформулировать правило: каждый раз, когда маршрутизатор получает Downstream MP2MP метку, он реагирует созданием Upstream MP2MP метки и отправлением её в сторону Upstream соседа.


Таким образом на текущий момент организуется дерево от РЕ до ROOT.


В ответ на получение метки 1014, ROOT генерирует метку 8017 которая для Р1 будет являться Upstream меткой. В ответ на получение 8017, Р1 генерирует Downstream метку 1013 и отправляет её в сторону PE1.



Добавим настройку на РЕ4:


PE4(config-subif)#ip vrf C-ONEPE4(config-vrf)# vpn id 65001:1PE4(config-vrf)# mdt default mpls mldp 8.8.8.8

*Nov 21 23:25:03.638: %PIM-5-NBRCHG: VRF C-ONE: neighbor 1.1.1.1 UP on interface Lspvif0

Обратите внимание, что mLDP метки на R8 (ROOT) никоим образом не меняются при появлении нового устройства. Это происходит из-за того, что Р1 не создаёт новую метку при получении сигнализации от РЕ4 в силу того, что сообщаемая метка от РЕ4 принадлежит тому же FEC, что полученная ранее от PE1.


Однако на Р1 появляются новые метки (и это ожидаемо, т.к. РЕ4 произвёл дополнительную сигнализацию):


P1#show mpls mldp database               * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 3   Type: MP2MP   Uptime : 00:46:10  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    8.8.8.8:0    [Active]      Expires        : Never         Path Set ID  : 9      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*      Local Label (D): 1014          Next Hop     : 10.5.8.8  Replication client(s):     1.1.1.1:0       Uptime         : 00:46:10      Path Set ID  : A      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*      Local label (U): 1013          Next Hop     : 10.1.5.1    4.4.4.4:0       Uptime         : 00:02:11      Path Set ID  : B      Out label (D)  : 40017         Interface    : GigabitEthernet2.45*      Local label (U): 1012          Next Hop     : 10.4.5.4


Стоит создать дополнительный VRF C-TWO на РЕ4, как сигнализируется дополнительное дерево с новыми метками.


PE4(config)#ip vrf C-TWOPE4(config-vrf)# rd 4.4.4.4:2PE4(config-vrf)# vpn id 65001:2PE4(config-vrf)# mdt default mpls mldp 8.8.8.8PE4(config-vrf)# route-target export 65001:2PE4(config-vrf)# route-target import 65001:2

RR#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 1   Type: MP2MP   Uptime : 00:54:07  FEC Root           : 8.8.8.8 (we are the root)  Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    None      Expires        : N/A           Path Set ID  : 1  Replication client(s):     5.5.5.5:0       Uptime         : 00:54:06      Path Set ID  : 2      Out label (D)  : 1014          Interface    : GigabitEthernet2.58*      Local label (U): 8017          Next Hop     : 10.5.8.5LSM ID : 2   Type: MP2MP   Uptime : 00:00:48  FEC Root           : 8.8.8.8 (we are the root)  Opaque decoded     : [mdt 65001:2 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000200000000  Upstream client(s) :    None      Expires        : N/A           Path Set ID  : 3  Replication client(s):     5.5.5.5:0       Uptime         : 00:00:48      Path Set ID  : 4      Out label (D)  : 1019          Interface    : GigabitEthernet2.58*      Local label (U): 8018          Next Hop     : 10.5.8.5

Проверим связность между сайтами, находящимися за РЕ1 и РЕ4.


CE1#ping 230.0.0.1 source Lo0Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11 Reply to request 0 from 14.14.14.14, 15 ms

Связность есть, что хорошо. Однако, давайте задумаемся над одним вопросом по каком пути ходит трафик? Доходит ли он до корневого маршрутизатора и потом возвращается обратно (так называемый U-turn) или же P1 может передавать пакеты напрямую в сторону РЕ4?


Чтобы ответить на этот вопрос, проанализируем таблицу меток на Р1 и ROOT и дополнительное воспользуемся Wireshark.


Мы уже знаем, что для передачи многоадресного трафика РЕ1 будет использовать метку 1013 (см пояснения выше) (для интерфейса 802.1Q vlan id = 15). Это подтверждается дампом трафика.



Что делает Р1 при получении данной метки?


P1#show mpls forwarding-table labels 1013Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    Label      Label      or Tunnel Id     Switched      interface              1013       8017       [mdt 65001:1 0]  198024        Gi2.58     10.5.8.8               40017      [mdt 65001:1 0]  184856        Gi2.45     10.4.5.4 

На что здесь необходимо обратить пристальное внимание. P1 знает об этой метке, т.к он сам её сгенерировал (смотри вывод show mpls mldp database ранее). Ранее мы с Вами говорили о том, что РЕ передаёт пакет в сторону ROOT, а уже ROOT должен вернуть пакет обратно на заинтересованные РЕ. Однако в данном примере видно, что при получении пакета на Р1, он раздваивается и отправляется в сторону РЕ4 и ROOT. Т.е U-turn не происходит из-за того, что Р1 видит


  • Downstream сигнализацию от РЕ4
  • Upstream передачу данных от РЕ1

В результате Р1 коммутирует MPLS пакеты напрямую, отправляя на ROOT копию трафика.


На ROOT на текущий момент пакет должен быть уничтожен:


RR#show mpls forwarding-table | i 80178017       No Label   [mdt 65001:1 0]  0

Активируем VRF на всех остальных РЕ. В результате можем ожидать создания интерфейсов типа Lspvif на каждом РЕ устройстве и установление PIM соседства между ними.


PE1#show ip pim vrf C-ONE neighbor | i Lsp3.3.3.3           Lspvif0                  00:01:02/00:01:41 v2    1 / S P G2.2.2.2           Lspvif0                  00:01:09/00:01:40 v2    1 / S P G4.4.4.4           Lspvif0                  10:49:57/00:01:40 v2    1 / DR S P G

Дополнительно, проверим таблицу коммутации на ROOT и убедимся, что теперь для метки 8017 (которая была получена от Р1) есть собственная локальная метка.


RR#show mpls forwarding-table | i 80178017       2013       [mdt 65001:1 0]  982           Gi2.68     10.6.8.6 


Рассмотренный выше вариант реализации multicast VPN известен под кодовым именем Profile 1. Его основные характеристики:


  • Нет необходимости в P-PIM для опорной сети
  • В качестве PMSTI используется интерфейс Lspvif
  • Нет необходимости в специализированном адресном семействе BGP
  • Для передачи трафика используется Default MDT
  • Построение Default MDT осуществляется с помощью протокола mLDP.
    • Проблема с тем, что многоадресный трафик коммутируется в сторону всех РЕ (в рамках VPN) также присутствует, как и в Profile 0.
  • В качестве протокола многоадресной маршрутизации внутри C-VRF на опорной сети используется протокол PIM (автоматически активируется на интерфейсе Lspvif)

Продолжение следует...

Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 3 BGP Auto-Discovery)

25.11.2020 02:13:20 | Автор: admin

В прошлых выпусках мы с Вами познакомились с понятиями Default MDT, типами корневых деревьев и разобрали два варианта реализации mVPN на основе mGRE и mLDP:
Profile 0
Profile 1


На сегодняшний день адресное семейство BGP MDT (которое уже рассматривали) является устаревшим. Ему на замену пришло новое SAFI = multicast VPN (mVPN). Что нового приносит данное адресное семейство? Какие случаи использования могут быть? Попробуем разобраться.


Заинтересованным добро пожаловать под кат.


Авторы идеи предложили разделить сообщение BGP update на две составляющие:


  • Непосредственно mvpn NLRI. Внутри передаётся следующая информация:
    • Типа маршрута (значение от 1 до 7). У каждого маршрута своя функция.
  • Аттрибуты туннеля PMSI (PMSI Tunnel Attribute, PTA). Отвечают за передачу информации о типе корневого дерева.

Типы BGP mVPN маршрутов


Тип маршрута Имя Предназначение
1 Intra-AS I-PMSI A-D объявление РЕ в качестве mVPN участника для конкретного VPN. Это BGP Auto-Discovery.
2 Inter-AS I-PMSI A-D объявление ASBR в качестве mVPN участника для конкретного VPN. Используется для построения Inter-AS mVPN.
3 S-PMSI A-D объявление РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группыПереключение на Data MDT (подробнее разберёмся позднее)
4 Leaf A-D ответ на Inter-AS PMSI A-D или S-PMSI A-D в случае выставленного бита Leaf Information (LI)
5 Source Active A-D сообщение Source Active
6 Shared Tree Join эквивалент сообщения PIM (*, G) Join (или Prune)
7 Source Tree Join эквивалент сообщения PIM (S, G) Join (или Prune)

PTA


Тип туннеля определяет используемое корневое дерево и может принимать одно из следующих значений:


0 информация не представлена
1 RSVP-TE P2MP LSP
2 mLDP P2MP LSP
3 PIM-SSM
4 PIM-SM
5 BIDIR-PIM
6 Ingress Replication
7 mLDP MP2MP LSP


Дополнительные community


В зависимости от того, используется ли BGP для сигнализации многоадресного трафика в рамках VRF, у маршрутов могут появляться дополнительные коммьюнити.


VRF Route Import (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Импортирование многоадресных маршрутов (подобную функцию в vpnv4 выполняет аттрибут Route-Target)


Route Target Constraint (RTC)
Предназначение:
В случае наличия RTC, Route-Reflector (или любой другой РЕ) отправляет только желаемый vpnv4/vpnv6 префикс к РЕ. Желаемый обозначает, что на принимаемом РЕ есть один или более VRF, в который указанный префикс может быть импортирован.


Прим. Более подробно про RTC написано в RFC4684


Source-AS Extended Community (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Передача AS информации для организации Inter-AS mVPN сценариев


PE Distinguisher Label
Предназначение:
Построение PPMP дерева для участия в Partitioned MDT (на текущий момент я не планирую рассматривать данное дерево в рамках цикла статей).


Поскольку с появлением SAFI mVPN функционал BGP очень расширился, то и применять данное SAFI можно для разных сценариев, в частности:


  • проведение Auto-Discovery
  • замена PIM сигнализации на BGP

Стоит отметить, что два вышеуказанных сценария могут быть задействованы как одновременно, так и по-отдельности.


Сначала рассмотрим случай когда в наложенной сети сохраняется PIM, но поиск заинтересованных РЕ происходит посредством BGP. Передача данных между РЕ осуществляется посредством GRE. Данная реализация известна под кодовым именем Profile 3.


Как и раньше, будем использовать следующую лабораторную топологию:



Начальные условия:


  • В рамках опорной сети:
    • настроен OSPF
    • настроен P-PIM в режиме SSM
      access-list 99 permit 239.1.1.0 0.0.0.255ip pim ssm range 99
      
  • В рамках VRF:
    • настроен C-PIM
    • нет активных источников или получателей трафика
  • VRF приведена к виду
    ip vrf C-ONErd 1.1.1.1:1route-target export 65001:1route-target import 65001:1
    

В первую очередь рассмотрим ситуацию, когда в рамках vrf C-ONE работает C-PIM SSM.


Настройка СЕ Настройка РЕ
access-list 99 permit 230.1.1.0 0.0.0.255
ip pim ssm range 99

access-list 98 permit 230.1.1.0 0.0.0.255
ip pim vrf C-ONE ssm range 98

На всех РЕ:


ip vrf C-ONEmdt auto-discovery pimmdt default 239.1.1.1

На РЕ устройствах поднимается новый PMSTI:


*Nov 24 20:44:40.941: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

PE1#show int tu2Tunnel2 is up, line protocol is upInterface is unnumbered. Using address of Loopback0 (1.1.1.1)Tunnel source 1.1.1.1 (Loopback0)Tunnel protocol/transport multi-GRE/IP

Пока что нет PIM соседства (т.к. РЕ не знают друг о друге):


*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

Активируем адресное семейство ipv4 mvpn:


router bgp 65001!address-family ipv4 mvpnneighbor MPLS_PE send-community extendedneighbor MPLS_PE route-reflector-clientneighbor 1.1.1.1 activateneighbor 2.2.2.2 activateneighbor 3.3.3.3 activateneighbor 4.4.4.4 activateexit-address-family

На РЕ моментально появляются соседи в рамках C-VRF:


PE1#show ip pim vrf C-ONE neighbor172.1.11.11    GigabitEthernet2.111   2w3d/00:01:19   v2  1 / DR S P G172.1.15.15    GigabitEthernet2.115   2w3d/00:01:35   v2  1 / DR S P G4.4.4.4      Tunnel2         00:00:17/00:01:27 v2  1 / DR S P G3.3.3.3      Tunnel2         00:00:17/00:01:27 v2  1 / S P G2.2.2.2      Tunnel2         00:00:47/00:01:27 v2  1 / S P G

И соответствующие (S, G) деревья:


PE1#show ip mroute 239.1.1.1(1.1.1.1, 239.1.1.1), 00:00:45/00:02:44, flags: sTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.15, Forward/Sparse, 00:00:45/00:02:44(4.4.4.4, 239.1.1.1), 00:00:49/00:02:10, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:00:49/00:02:10(3.3.3.3, 239.1.1.1), 00:00:53/00:02:06, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:00:53/00:02:06(2.2.2.2, 239.1.1.1), 00:01:19/00:01:40, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:01:19/00:01:40

Как РЕ смогли увидеть друг друга? Ответ на этот вопрос нам даст анализ BGP таблицы:


PE1#show bgp ipv4 mvpn allBGP table version is 258, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i  internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i  IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Как видим, каждый РЕ маршрутизатор создал BGP IPv4 mvpn маршрут первого типа, в котором описал себя


PE1#show bgp ipv4 mvpn all route-type 1 4.4.4.4BGP routing table entry for [1][1.1.1.1:1][4.4.4.4]/12, version 262Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Not advertised to any peerRefresh Epoch 1Local, imported path from [1][4.4.4.4:1][4.4.4.4]/12 (global)4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestCommunity: no-exportExtended Community: RT:65001:1Originator: 4.4.4.4, Cluster list: 8.8.8.8PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101rx pathid: 0, tx pathid: 0x0BGP routing table entry for [1][4.4.4.4:1][4.4.4.4]/12, version 265Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Not advertised to any peerRefresh Epoch 1Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestCommunity: no-exportExtended Community: RT:65001:1Originator: 4.4.4.4, Cluster list: 8.8.8.8PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101rx pathid: 0, tx pathid: 0x0

Обратите внимание на PTA:


  • Tunnel type: 3 говорит нам о том, что в рамках vrf использует SSM PIM
  • tunnel parameters сообщает нам об адресе РЕ и группе многоадресной рассылки (EF01 0101 = 239.1.1.1)

Подключим клиента:


CE4(config-if)#ip igmp join-group 230.1.1.1 source 11.11.11.11

На РЕ этого сайта появляется многоадресный маршрут:


PE4#show ip mroute vrf C-ONE(11.11.11.11, 230.1.1.1), 00:00:11/00:03:18, flags: sTIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:11/00:03:18

В качестве RPF nbr указан адрес 1.1.1.1 как PE4 вычисляет его? На самом деле очень просто. Это адрес BGP next-hop для источника = 11.11.11.11


PE4#show ip route vrf C-ONE 11.11.11.11Routing Table: C-ONERouting entry for 11.11.11.11/32  Known via "bgp 65001", distance 200, metric 0  Tag 65011, type internal  Last update from 1.1.1.1 01:02:10 ago  Routing Descriptor Blocks:  * 1.1.1.1 (default), from 8.8.8.8, 01:02:10 ago      Route metric is 0, traffic share count is 1      AS Hops 1      Route tag 65011      MPLS label: 10018      MPLS Flags: MPLS Required

Соответственно, РЕ4 генерирует PIM Join и отправляет его в рамках Default MDT:



Данный PIM Join будет получен всеми РЕ, но обработан только на РЕ1 (т.к. только на нём Join пройдет RPF проверку)


PE1#show ip mroute vrf C-ONE | b \((11.11.11.11, 230.1.1.1), 00:01:16/00:03:11, flags: sTIncoming interface: GigabitEthernet2.111, RPF nbr 172.1.11.11Outgoing interface list:Tunnel2, Forward/Sparse, 00:01:16/00:03:11

PE2#show ip mroute vrf C-ONE | b \(PE2#

Проверим работоспособность сервиса:


CE1#pingTarget IP address: 230.1.1.1Repeat count [1]: 5Extended commands [n]: yInterface [All]: GigabitEthernet2.111Source address or interface: 11.11.11.11Sending 5, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 8 msReply to request 3 from 14.14.14.14, 8 msReply to request 4 from 14.14.14.14, 7 ms

Как видно, многоадресные пакеты корректно передаются через опорную сеть. При этом стоит отметить, что способ передачи пакетов ничем не отличается от того, что мы с Вами наблюдали в рамках Profile0. Т.е. пакеты долетают до всех РЕ в рамках Default MDT и уже там отбрасываются в случае отсутствия активных подписчиков.



В этом можно убедиться, сняв дамп трафика на сети как это показано на рисунке ниже (vlan id = 37 характеризует интерфейс между R3 и R7):



Выше мы рассмотрели случай использования PIM SSM внутри C-VRF. Изменится ли что-либо, если будет работать PIM ASM?


CE4(config-if)#interface Lo0CE4(config-if)#ip igmp version 2CE4(config-if)#no ip igmp join-group 230.1.1.1 source 11.11.11.11CE4(config-if)#ip igmp join-group 231.1.1.1!CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0!CE15(config)#access-list 1 permit 231.1.1.0 0.0.0.255CE15(config)#ip pim bsr-candidate Lo0CE15(config)#ip pim rp-candidate Lo0 group-list 1

На РЕ сайта появляется дополнительный туннельный интерфейс для PIM encap:


PE1#*Nov 24 21:39:32.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Все маршрутизаторы внутри C-VRF корректно узнают о появившихся RP и BSR устройствах в сети:


CE1#show ip pim bsr-routerPIMv2 Bootstrap informationBSR address: 15.15.15.15 (?)Uptime:   00:01:54, BSR Priority: 0, Hash mask length: 0Expires:   00:01:16

До тех пор, пока нет активного источника трафика, внутри C-VRF будут наблюдаться только (*, G) маршруты согласно обычной логике работы PIM ASM:


PE4#show ip mroute vrf C-ONETimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 231.1.1.2), 00:00:46/00:02:43, RP 15.15.15.15, flags: SIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:46/00:02:43

При этом внутри BGP домена не появляется никаких дополнительных mvpn префиксов:


PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>i [1][1.1.1.1:1][1.1.1.1]/121.1.1.1         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1 (default for vrf C-ONE)*>i [1][4.4.4.4:1][1.1.1.1]/121.1.1.1         0  100   0 ?*>i [1][4.4.4.4:1][2.2.2.2]/12Network     Next Hop      Metric LocPrf Weight Path2.2.2.2         0  100   0 ?*>i [1][4.4.4.4:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>  [1][4.4.4.4:1][4.4.4.4]/12


Почему? спросите Вы? Потому что для сигнализации многоадресного трафика C-VRF используется протокол PIM.


О возможной замене сигнализации на BGP поговорим в следующий раз.

Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 4 BGP сигнализация)

27.11.2020 00:13:20 | Автор: admin
В предыдущих выпусках:

Profile 0
Profile 1
Profile 3

В этой части статьи мы рассмотрим с Вами вариант замены сигнализации в рамках наложенной сети с протокола PIM на BGP.

Как рассматривалось ранее (см статью про BGP Auto-Discovery), для того чтобы передавать аналоги PIM сообщений, в BGP было придумано несколько типов маршрутов, каждый из которых несёт в себе определённый функционал. При этом типов маршрутов больше, чем есть типов сообщений у PIM.



Зачем натягивать сову на глобус? можете спросить Вы, ведь всё прекрасно работает и с PIM. И, в общем-то, будете правы. Основной причиной эдакого ходя конём является масштабируемость. PIM, являясь по сути своей Soft Driven протоколом, требует для своей работы постоянной рассылки служебных сообщений, что при определённом размере внедрения (если количество узлов начинает переваливать за пару сотен или тысяч) привносит ограничения в связи с неизбежной загрузкой CPU. BGP же является Hard Driven протоколом т.е. если что-то было сказано однажды, то не повторяется; любые BGP обновления вызваны исключительно изменениями в сети.

Сегодня мы с Вами рассмотрим два сценария: использование PIM SSM и PIM ASM в рамках C-VRF.

C-PIM SSM


Для более простого понимания BGP сигнализации для построения многоадресных деревьев, начнём наш разговор с более простого PIM SSM.

Прежде всего, уберём текущие настройки точки рандеву и отключим получателей трафика:

CE4(config)#interface Loopback0CE4(config-if)#no ip igmp join-group 231.1.1.2CE4(config-if)#CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0 group-list 1

На всех РЕ укажем, что для сигнализации вместо PIM будет работать BGP. Это делается следующей командой:

ip vrf C-ONEmdt overlay use-bgp

Отправной точкой наблюдений будет ситуация без наличия источников и получателей многоадресного трафика. В BGP таблице должны присутствовать только type-1 маршруты:

PE1#show bgp ipv4 mvpn allBGP table version is 406, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Подключим получателя:

CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11

На ближайшем РЕ создаётся BGP маршрут 7-го типа это эквивалент сообщения PIM (S, G) Join:

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/220.0.0.0              32768 ?

По логике вещей, данный маршрут должен присутствовать только на РЕ4 и на РЕ1 (т.к именно через них должен проходить трафик) и отсутствовать на РЕ2 и РЕ3. Проверим:

PE1#show bgp ipv4 mvpn all | b \[7\]*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/224.4.4.4         0  100   0 ?PE2#show bgp ipv4 mvpn all | b \[7\]PE2#PE3#show bgp ipv4 mvpn all | b \[7\]PE3#

Как так получается, что маршрут, изначальной порождённый на РЕ4, импортируется только на РЕ1?

Посмотрим на запись в BGP-таблице чуть детальнее:

PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:7Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В записи префикса присутствует расширенное коммьюнити Route-target = 1.1.1.1:1, которое было добавлено в vpnv4 префикс маршрутизатором, который с точки РЕ4 является RPF соседом:

PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1     17Refresh Epoch 465011172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)Origin IGP, metric 0, localpref 100, valid, external, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1mpls labels in/out 10018/nolabelrx pathid: 0, tx pathid: 0x0PE1#PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 15265011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10018rx pathid: 0, tx pathid: 0x0

Проверим связность:

CE1#ping 230.1.1.1 so 11.11.11.11 rep 3Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 0 from 14.14.14.14, 8 msReply to request 1 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 9 msReply to request 2 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 7 ms

C-PIM ASM


В случае работы C-PIM в режиме SSM всё довольно просто. Для корректной работы mVPN достаточно создания двух дополнительных (типов) BGP маршрутов.

А как обстоят дела, если внутри C-VRF используется более комплексный ASM PIM?

Прежде всего мы видим, что на всех СЕ известна информация о точке рандеву:

CE2#show ip pim rp mappCE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 231.1.1.0/24RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 1d04h, expires: 00:02:09CE2#

Как? Если мы посмотрим BGP таблицу, то не найдём там никакого намёка на эту точку:

PE1#show bgp ipv4 mvpn allBGP table version is 682, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Не надо забывать о том, что у нас есть PMSTI, на котором активирован PIM:

PE1#show ip pim vrf C-ONE interfaceAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Tunnel2         v2/S  0   30   1     1.1.1.1



Отсюда можно сделать важный вывод некоторые сообщения PIM (даже при BGP сигнализации) передаются поверх опорной сети в рамках Default MDT.


Представим, что в сети появился источник (за маршрутизатором СЕ2). Поскольку на СЕ2 на данный момент нет записей в mRIB, то PIM Designated Router (в нашем случае это сам СЕ2) отправляет сообщение Register на точку рандеву, тем самым сигнализируя о наличии активного источника в сети.


На точке рандеву создаётся дерево (12.12.12.12, 231.1.1.1):

CE5#show ip mroute | b \((*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SPIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list: Null(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: PIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

И, поскольку, в сети нет активных получателей трафика (отсутствует дерево (*, 231.1.1.1)), то со стороны CE5 создаётся сообщение Register-Stop



В ответ на получение Register-Stop, CE2 приостанавливает передачу данных (нет интерфейсов в OIL):

CE2#show ip mroute 231.1.1.1(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list: Null

Теперь представим, что в сети появился получатель, заинтересованный в трафике для группы 231.1.1.1. На РЕ4 появляется маршрут внутри C-VRF:

PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \((*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45

И создаётся BGP маршрут 6-го типа, который является эквивалентом PIM Join (*, 231.1.1.1):

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/220.0.0.0              32768 ?PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В приведённом выше выводе необходимо обратить внимание на расширенное коммьюнити Route-target = 1.1.1.1:1. Что это и откуда взялось?

Проверим наличие данного префикса на других РЕ:

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698Paths: (1 available, best #1, table MVPNv4-BGP-Table)Not advertised to any peerRefresh Epoch 2Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1.1.1.1:1Originator: 4.4.4.4, Cluster list: 8.8.8.8rx pathid: 0, tx pathid: 0x0

Т.е. префикс существует только на РЕ1. Что интересно, так это тот факт, что точка рандеву (15.15.15.15) находится именно на сайте за РЕ1.

Зная назначение Route-target (импорт маршрутов внутрь определённой VRF) напрашивается вывод RT = 1.1.1.1:1 известен РЕ1 и неизвестен РЕ2/PE3. Т.е очевиден факт, что РЕ4 сгенерировал BGP маршрут, описывающий PIM Shared Tree Join таким образом, чтобы он был обработан только на том РЕ, за которым в действительности находится точка рандеву (по факту, это аналог передачи PIM Join через RPF интерфейс). Но каким образом РЕ1 и РЕ4 согласуют между собой значения Route-target?

PE4 проводит RPF для адреса точки рандеву:

PE4#show ip rpf vrf C-ONE 15.15.15.15RPF information for ? (15.15.15.15)RPF interface: Tunnel0RPF neighbor: ? (1.1.1.1)RPF route/mask: 15.15.15.15/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 1.1.1.1RPF topology: ipv4 multicast base, originated from ipv4 unicast base

В качестве RPF соседа виден РЕ1. Значит, РЕ4 должен поместить внутрь маршрута 6-го типа такой Route-target, который будет импортирован только РЕ1. Чтобы ответить на вопрос откуда РЕ4 его знает? посмотрим, для начала, на vpn маршрут:

PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 165015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10013rx pathid: 0, tx pathid: 0x0

Обратите внимание на дополнительное коммьюнити MVPN VRF:1.1.1.1:1. Это ничто иное, как коммьюнити Route Import, сгенерированное РЕ1. Именно это значение копируется как Route-target внутрь многоадресного маршрута, что позволяет РЕ1 импортировать полученный апдейт от РЕ4.

Результатом обработки BGP маршрут 6-го типа на РЕ4 является создание записи в многоадресной таблице маршрутизации:

PE4#show ip mroute vrf C-ONE(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33

Прим обратите внимание, что входным интерфейсом указан Tunnel0 (PMSTI).

На точке рандеву завершается создание общего дерева:

CE5#show ip mroute | b \((*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22



Теперь, если в сети опять появится активный источник трафика, точка рандеву будет знать как совместить (*, 231.1.1.1) и (12.12.12.12, 231.1.1.1) деревья.

CE5#show ip mroute | b \((*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PTIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP маршрут 7-го типа:

PE1#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1*>  [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/220.0.0.0              32768 ?PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:2.2.2.2:1rx pathid: 1, tx pathid: 0x0

Обратите внимание, что в качестве Remote VPN RD выставляется значение 2.2.2.2:1, т.к. именно через РЕ2 завершается RPF проверка маршрута:

PE1#show ip rpf vrf C-ONE 12.12.12.12RPF information for ? (12.12.12.12)RPF interface: Tunnel2RPF neighbor: ? (2.2.2.2)RPF route/mask: 12.12.12.12/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 2.2.2.2RPF topology: ipv4 multicast base, originated from ipv4 unicast base

И RT 2.2.2.2:1 был добавлен в VPNv4 префикс со стороны РЕ2:

PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 265012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1Originator: 2.2.2.2, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 2.2.2.2:1:2.2.2.2mpls labels in/out nolabel/31rx pathid: 0, tx pathid: 0x0

На этом шаге, по сути, завершается построение дерева (12.12.12.12, 231.1.1.1) на участке между источником и точкой рандеву:


После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го типа, сигнализируя о наличии активного источника трафика в сети. Маршрут импортируется всеми РЕ устройствами.

PE2#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)*>  [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/180.0.0.0              32768 ?PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1rx pathid: 0, tx pathid: 0x0

При получении маршрута 5-го типа, на РЕ4 (где находится получатель) завершается создание многоадресного дерева:

PE4#show ip mroute vrf C-ONE(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQIncoming interface: Tunnel0, RPF nbr 2.2.2.2Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19

Прим обратите внимание на флаг Q, который говорит о том, что запись была создана благодаря сообщению BGP Source-Active


Рассмотренный вариант организации mVPN носит кодовое имя Profile 11. Его основные характеристики:

  • для передачи многоадресного трафика наложенной сети используется Default MDT
  • в качестве метода организации транспорта выступает протокол mGRE
  • для сигнализации многоадресного дерева в рамках наложенной сети используется протокол BGP
Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 5 знакомство с DataPartitioned MDT)

05.12.2020 22:10:10 | Автор: admin
В предыдущих выпусках:

Profile 0
Profile 1
Profile 3
Profile 11

Как мы узнали из прошлых записей, в опорной сети при реализации mVPN всегда присутствует конструкция Default MDT, к которой подключены все РЕ маршрутизаторы. В рамках данного MDT передаются служебные сообщения PIM (например Bootstrap, Auto-RP), а также пользовательский многоадресный трафик. В результате получается, что какие-то РЕ устройства получают даже тот трафик, на который они не подписывались.

Если хотите узнать как с этим бороться добро пожаловать под кат!



Для того чтобы повысить эффективность передачи данных используется дополнительная конструкция, которая именуется как Data MDT. Идея, которая лежит в её основе, заключается в следующем:
  • В рамках дерева распространяется только C-(S, G) трафик
  • Участниками дерева становятся только те Egress PE, у которых есть заинтересованные получатели
  • Корневым устройством Data MDT является Ingress PE (маршрутизатор, за которым находится источник)


Визуально это выглядит следующим образом:



Если представить ситуацию, в которой источник начинает вещать на вторую многоадресную группу (230.1.1.2), получатели для которой находятся только за РЕ2 и РЕ3, то создаётся дополнительное Data MDT и общая картинка приобретает вид (Default MDT опущено):



Сигнализация по переключению трафика от Default MDT к Data MDT осуществляется исключительно по-требованию при превышении заданного порога со стороны Ingress PE либо средствами PIM, либо средствами BGP.



Data MDT с помощью PIM


Если для сигнализации используется PIM, то ingress PE генерирует специальное сообщение PIM Data-MDT TLV и отправляет его в рамках Default MDT чтобы быть уверенным в том, что все РЕ смогут получить данное сообщение. Одновременно с отправкой Data MDT TLV, Ingress PE запускает таймер, равный трём секундам. По истечении таймера, все пакеты будут передаваться в рамках Data MDT.

Также необходимо отметить тот факт, что информация, содержащаяся в Data-MDT TLV кешируется на всех РЕ. Причина тому довольно банальна даже если в текущий момент на конкретном РЕ нет заинтересованных получателей трафика, они могут появиться там спустя некоторое время. Соответственно, при получении PIM Join (внутри C-VRF) PE может моментально подключиться к уже существующему на сети Data MDT.

Прим. Data-MDT TLV передаются раз в минуту.

Каждое Data MDT устанавливается для отдельного (S, G) маршрута в рамках VPN/VRF. Администратору необходимо явно указать максимальное количество Data MDT, которое может быть создано на устройстве. Если в какой-то момент количество вновь устанавливаемых деревьев достигает заданного предела, то следующие деревья будут переиспользовать уже установленные.

Прим. На момент написания статьи, Cisco IOS не поддерживает PIM сигнализацию поверх Data MDT. Все профили с данной сигнализацией доступны только на операционной системе IOS XR.

Data MDT с помощью BGP


При использовании BGP в наложенной сети для сигнализации Data MDT, основные принципы остаются неизменными (по сравнению с PIM):
  • ingress PE сигнализирует всем РЕ о том, что трафик для C-(S,G) будет передаваться в рамках Data MDT
  • egress PE при получении BGP апдейта присоединяется к указанному дереву
  • для сигнализации используется адресное семейство mVPN (sAFI 129).


Получается, что Ingress PE должен сформировать специальное BGP Update сообщение и отправить его всем РЕ в рамках mVPN. Для этого используется маршрут третьего типа.

Profile 14


Рассмотрим описанный переход на примере нашей лаборатории. В частности, применим конфигурацию, известную как Profile 14. Данный профиль характеризуется использованием BGP mVPN A-D для построения P2MP MLDP LSP.

На РЕ будем использовать следующий шаблон конфигурации:

ip vrf C-ONE
mdt auto-discovery mldp
mdt partitioned mldp p2mp
mdt overlay use-bgp
mdt strict-rpf interface
!
router bgp 1
address-family ipv4 mvpn
neighbor 8.8.8.8 activate
neighbor 8.8.8.8 send-community extended
exit-address-family


Прим. о предназначении команды mdt strict-rpf interface поговорим в следующем выпуске.

Auto-Discovery


Посмотрим, что происходит на РЕ1:

На каждом РЕ создаётся интерфейс Lspvif0, на котором активируется C-PIM.

*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up

Никаких соседей на данный момент нет:

PE1#show ip pim vrf C-ONE intAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Lspvif0         v2/S  0   30   1     1.1.1.1


Посмотрим BGP таблицу:

PE1#show bgp ipv4 mvpn allBGP table version is 39, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [3][1.1.1.1:1][*][*][1.1.1.1]/140.0.0.0              32768 ?*>i [3][1.1.1.1:1][*][*][2.2.2.2]/142.2.2.2         0  100   0 ?*>i [3][1.1.1.1:1][*][*][3.3.3.3]/143.3.3.3         0  100   0 ?*>i [3][1.1.1.1:1][*][*][4.4.4.4]/144.4.4.4         0  100   0 ?*>  [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/180.0.0.0              32768 ?Route Distinguisher: 2.2.2.2:1*>i [3][2.2.2.2:1][*][*][2.2.2.2]/142.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1*>i [3][3.3.3.3:1][*][*][3.3.3.3]/143.3.3.3         0  100   0 ?Network     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 4.4.4.4:1*>i [3][4.4.4.4:1][*][*][4.4.4.4]/144.4.4.4         0  100   0 ?


Как видно, в дополнение к уже рассмотренным ранее маршрутам первого типа, добавляются маршруты третьего типа S-PMSI A-D, которые используются для объявления РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группы. На текущий момент группа равна (*, *). Это говорит о желании РЕ участвовать в построении Partitioned MDT.

Очевидно, чтобы заработала передача данных, в рамках VRF должна быть известна информация о точке рандеву. В нашем случае в качестве RP и BSR выступает CE15.

C-RP#sh run | i pimip pim bsr-candidate Loopback0 0ip pim rp-candidate Loopback0

Поскольку у C-RP построено PIM соседство с PE1, то на этом РЕ1 информация об RP также известна:

PE1#show ip pim vrf C-ONE rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 224.0.0.0/4RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 01:25:50, expires: 00:01:26

Необходимо доставить эту информацию до всех остальных PE/CE. Как это сделать? Чтобы лучше понять принцип, предлагаю пойти от обратного и начать просмотра уже известной информации на СЕ2:

CE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 224.0.0.0/4RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 01:27:54, expires: 00:02:26

Как видим, сообщения PIM BSR распространилось по mVPN инфраструктуре. Посмотрим дамп трафика на РЕ1:


Как видим PE1 инкапсулирует сообщение PIM BSR внутрь MPLS и помечает его меткой 28. Откуда она берётся? Можем предположить, что поскольку этот пакет достиг СЕ2 (а значит и РЕ2), то есть некий LSP до РЕ2.

PE2#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 1  Type: P2MP  Uptime : 04:17:40FEC Root      : 2.2.2.2 (we are the root)Opaque decoded   : [gid 65536 (0x00010000)]Opaque length   : 4 bytesOpaque value    : 01 0004 00010000Upstream client(s) :NoneExpires    : N/A      Path Set ID : 1Replication client(s):>  MDT (VRF C-ONE)Uptime     : 04:17:40   Path Set ID : NoneInterface   : Lspvif0    RPF-ID    : *LSM ID : 3  Type: P2MP  Uptime : 01:30:06FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :6.6.6.6:0  [Active]Expires    : Never     Path Set ID : 3Out Label (U) : None     Interface  : GigabitEthernet2.26*Local Label (D): 34      Next Hop   : 10.2.6.6Replication client(s):MDT (VRF C-ONE)Uptime     : 01:30:06   Path Set ID : NoneInterface   : Lspvif0    RPF-ID    : *

Из анализа базы mLDP видно, что на РЕ2 есть некое дерево (LSM ID: 3), корнем которого является PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF и для этого дерева сгенерирована локальная метка 34, которая отправлена соседу R6 (P2).

Откуда РЕ2 узнал о дереве, корнем которого является PE1 да ещё и получил Opaque для него? Ответ прост с помощью BGP маршрута третьего типа.

Когда РЕ1 получил PIM BSR, то сгенерировал дополнительный BGP маршрут, который описывает группу (*, 224.0.0.13) (напоминаю, что это зарезервированный адрес для рассылки всех служебных PIM сообщений). Этот маршрут служит для объявления нового многоадресного mLDP дерева. Внутри РТА указано Opaque значение, которое необходимо использовать для сигнализации посредством mLDP.

PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:1Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FFrx pathid: 0, tx pathid: 0x0

Таким образом, РЕ2 импортируя этот маршрут, может начать mLDP сигнализацию в сторону РЕ1 для дерева (*, 224.0.0.13). Для полученной от РЕ2 метки, Р2 (R6) генерирует свой собственную локальную (29) и отправляет её в сторону P1 (R5):

P2#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 2  Type: P2MP  Uptime : 01:40:24FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :5.5.5.5:0  [Active]Expires    : Never     Path Set ID : 2Out Label (U) : None     Interface  : GigabitEthernet2.56*Local Label (D): 29      Next Hop   : 10.5.6.5Replication client(s):2.2.2.2:0Uptime     : 01:40:24   Path Set ID : NoneOut label (D) : 34      Interface  : GigabitEthernet2.26*Local label (U): None     Next Hop   : 10.2.6.2

Аналогичным образом поступает и Р1 (R5), генерируя свою локальную метку для дерева и отправляя её к РЕ1:

P1#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 2  Type: P2MP  Uptime : 01:41:24FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :1.1.1.1:0  [Active]Expires    : Never     Path Set ID : 2Out Label (U) : None     Interface  : GigabitEthernet2.15*Local Label (D): 28      Next Hop   : 10.1.5.1Replication client(s):4.4.4.4:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 34      Interface  : GigabitEthernet2.45*Local label (U): None     Next Hop   : 10.4.5.47.7.7.7:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 30      Interface  : GigabitEthernet2.57*Local label (U): None     Next Hop   : 10.5.7.76.6.6.6:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 29      Interface  : GigabitEthernet2.56*Local label (U): None     Next Hop   : 10.5.6.6

Визуально весь процесс представлен на рисунке ниже:


Присоединение к Shared Tree и построение корневого P2MP дерева (ROOT = RP-PE)


Шаг 2. В сети появляется получатель трафика. После того как Egress PE (РЕ2) получает PIM Join от CE для C-(*, G), PE2 производит RPF проверку чтобы найти BGP Next-Hop в сторону C-RP. Найденный Next-Hop (1.1.1.1) будет использоваться как Partitioned MDT ROOT для mLDP.

Дополнительно РЕ2 создаёт интерфейс Lspvif внутри C-VRF:

PE2#*Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to upPE2#*Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1

Шаг 3. Egress PE (PE2) генерирует сообщение mLDP mapping в сторону RP-PE (ROOT P2MP MDT) используя Opaque значение из BGP апдейта.

PE2#show mpls mldp database summaryLSM ID   Type  Root       Decoded Opaque Value     Client Cnt.4     P2MP  1.1.1.1      [gid 65536 (0x00010000)]   11     P2MP  2.2.2.2      [gid 65536 (0x00010000)]   13     P2MP  1.1.1.1      [gid 131071 (0x0001FFFF)]   1PE2#PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detailI-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI* - Indicates Wildcard source or group address[S-PMSI][1.1.1.1:1][*][*][1.1.1.1], JoinedOrig: Remote Uptime: 04:44:27 Type: MLDP P2MPRoot: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][3.3.3.3:1][*][*][3.3.3.3],Orig: Remote Uptime: 04:44:22 Type: MLDP P2MPRoot: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][4.4.4.4:1][*][*][4.4.4.4],Orig: Remote Uptime: 04:44:20 Type: MLDP P2MPRoot: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][2.2.2.2:1][*][*][2.2.2.2], JoinedOrig: Local Uptime: 04:44:24 Type: MLDP P2MPRoot: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000)PE2#show mpls mldp database opaque_type gid 65536LSM ID : 4  Type: P2MP  Uptime : 00:03:43FEC Root      : 1.1.1.1Opaque decoded   : [gid 65536 (0x00010000)]Opaque length   : 4 bytesOpaque value    : 01 0004 00010000Upstream client(s) :6.6.6.6:0  [Active]Expires    : Never     Path Set ID : 4Out Label (U) : None     Interface  : GigabitEthernet2.26*Local Label (D): 35      Next Hop   : 10.2.6.6Replication client(s):MDT (VRF C-ONE)Uptime     : 00:03:43   Path Set ID : NoneInterface   : Lspvif1    RPF-ID    : 0x1

Шаг 4. Egress PE генерирует BGP маршрут шестого типа (присоединение к Shared Tree в сторону RP-PE). Данный маршрут импортируется только на RP-PE.

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:1Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

Шаг 5. RP-PE транслирует полученный BGP маршрут шестого типа в PIM Join в сторону RP. На этот момент RP готово к отправке многоадресного трафика в сторону Egress PE. Необходимо доставить трафик от источника до RP.

PE1#show ip mroute vrf C-ONE | b \((*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SGIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15Outgoing interface list:Lspvif0, Forward/Sparse, 00:07:08/stopped



Шаг 6. Когда S-PE (PE4) получает первый многоадресный пакет от источника (CE4), трафик инкапсулируется внутрь сообщения PIM Register и отправляется как одноадресный пакет в сторону C-RP (используя обычные правила MPLS L3 VPN).

Шаг 7. После получения PIM Register, C-RP начинает процесс построения дерева С-(14.14.14.14, 230.1.1.1). RP-PE получает PIM Join для C-(14.14.14.14, 230.1.1.1) от C-RP. Данное сообщение транслируется в BGP маршрут седьмого типа. Однако, перед отправкой в сторону источника, необходимо построить новое дерево Partitioned MDT с РЕ в качестве ROOT.


Шаг 8. RP-PE производит RPF проверку чтобы найти BGP Next-Hop в сторону источника. Данный адрес будет использоваться как Partitioned MDT ROOT для mLDP.

Шаг 9. Используя полученный BGP Next-Hop и BGP маршрут третьего типа от Ingress PE, RP-PR генерирует сообщение mLDP mapping в сторону IP адреса Ingress PE, тем самым строя корневое P2MP дерево до Ingress PE.

Шаг 10. RP-PE отправляет BGP маршрут седьмого типа (Join от RP) в сторону Ingress PE.

Шаг 11. Ingress PE преобразует полученный BGP маршрут седьмого типа в PIM Join и отправляет его в сторону источника трафика.


Присоединение к Source Tree и построение P2MP (ROOT = S-PE)


Шаг 12. Ingress PE также отправляет BGP маршрут пятого типа ко всем mVPN PE, тем самым информируя их о наличии активного источника в сети. Данный маршрут является триггером для переключения к SPT дереву.

Шаг 13. Egress PE использует полученный BGP маршрут пятого типа для генерации сообщения mLDP mapping в сторону Ingress PE (информация о MDT берётся из BGP маршрута третьего типа).


Таким образом теперь трафик может быть перенаправлен оптимальным путём от источника к получателю, используя mpls (mLDP) метки.

Подробнее..

3 признака того, что вам нужна PIM система

08.12.2020 16:17:05 | Автор: admin


Поздравляю, у вас растущий интернет-магазин! Важные цифры посетители, продажи растут! Но подождите секунду, другие цифры, похоже, тоже растут отказ от корзины? Жалобы клиентов? Возвращения? И почему конверсии снижаются? Это плохо что здесь происходит?



Возможно, проблема в качестве информации о ваших товарах и пришло время инвестировать в систему, которая поможет вам справиться со всей сложностью информации о продукте. Мы называем это PIM, сокращение от Product Information Management (Управление информацией о продукте).

В этой статье мы рассмотрим некоторые общие вопросы, которые могут указывать на необходимость PIM. Но прежде, чем мы начнем, мы должны объяснить, что такое PIM, а что нет.

PIM это не только программное обеспечение


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

Короче говоря, PIM позволяет и упрощает многоканальную торговлю.

Любая компания, продающая товары, имеет дело с описанием продукции. Независимо от того, собирается ли она у поставщиков или производится внутри компании, печатается в каталоге или публикуется в Интернете, контент является критически важным компонентом маркетинга.

Поскольку добавление продуктов и категорий является постепенным, большинство онлайн-продавцов не чувствуют особых проблем, когда начинают с небольшого ассортимента продукции. Работа с контентом на первых порах проста, и это убаюкивает членов команды в ложное чувство безопасности, что приводит к плохим привычкам (читать: Excel ). Тем не менее, проблемы становятся очевидными, когда они пытаются увеличить масштаб или выполнить крупномасштабную миграцию данных.

Обычно мы рассматриваем информацию о продукте как все, что клиент может увидеть и с чем может взаимодействовать в рамках цифрового канала изображения, видео, описания, атрибуты, функции и преимущества, PDF-файлы и т.д. Все эти элементы связаны с основными данными о продукте информацией, необходимой для покупки и продажи этого продукта, включая бренд, UPC, номер SKU, присвоенной категории, информацию о поставщике и т.д.

Вот список 3 проблем, которые говорят о том, что пришло время инвестировать в PIM.

Проблема 1: Управление данными вызывает головную боль



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

Вероятно, самым очевидным внутренним признаком того, что вам нужен PIM, является то, что эти процессы представляют собой растущие затраты внутри вашей организации.

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

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

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

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

Проблема 2: Отсутствие гибкости и длительные сроки обработки



Непосредственным следствием слабых процессов управления данными является неэффективность, когда необходимо использовать данные о ваших продуктах для определенной цели, например, для выхода в новый канал.

Взгляните на этот пример:

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

Но компания А, которая считает себя бережливой, и использует свои собственные ручные процессы для управления данными о продуктах, в значительной степени полагаясь на нескольких ключевых людей внутри компании, которые создали свои собственные индивидуальные процессы на основе Excel для сбора и обработки информации о продуктах.

Компания Б, с другой стороны, инвестировала в PIM и строго контролирует сбор, обогащение, хранение и публикацию данных о продуктах.

Как обстоят дела у этих двух компаний, когда приходит время выгружать данные для маркетплейса?

Компания А



  1. Иван из отдела интернет-продаж и его коллеги управляют информацией о продукте, используя ручные процессы, включая электронную почту и электронные таблицы, и делают все возможное, чтобы поместить контент в ERP и/или платформу интернет-магазина.
  2. Иван просит Петра из ИТ-отдела подготовить файл с продуктовыми данными.
  3. Иван просматривает требования к данным для маркетплейса и вручную изменяет имена столбцов в Excel
  4. Иван вручную обновляет контент, не соответствующий требованиям маркетплейса, при необходимости обращаясь за помощью к своей команде или третьей стороне.
  5. Иван отфильтровывает товары и категории, не относящиеся к этому каналу.
  6. Иван передает файл обратно в ИТ, чтобы проверить файл и вручную исправить ошибки.
  7. Публикация
  8. Нужен обновленный файл? Повторите весь процесс.


Компания Б



  1. Сергей и его коллеги управляют информацией о продукте через централизованную PIM систему.
  2. Сергей создает новый процесс экспорта данных, соответствующий требованиям маркетплейса.
  3. Сергей прогоняет тестовую выгрузку данных и исправляет ошибки в экспорте если необходимо.
  4. Публикация
  5. Нужен обновленный файл? Запустите готовый экспорт снова или создайте автоматический процесс экспорта, который будет срабатывать в нужное время.


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

Проблема 3: плохой клиентский опыт в онлайн-каналах



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

И они ошибаются. Причина проста: PIM обеспечивает превосходное качество продуктовых данных, что ведет к улучшению клиентского опыта.

Рассмотрим следующие примеры:

Согласованность в продуктовых данных.


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

Фильтры и сравнение продуктов.


Согласованность также означает, что клиенты, использующие параметрические фильтры на ваших веб-сайтах, получают точные результаты. Сколько раз вы видели одно и то же значение атрибута, представленное разными способами? Один сантиметр, 1 сантиметр, 1 см.- это одно и то же значение, но ваша платформа не знает этого, если вы не применяете типы данных и единицы измерения, а это основная возможность PIM систем (и отличный пример того, что одного Excel не хватает). Возможности сравнения продуктов зависят от чистых, нормализованных данных.

Время вывода на рынок.


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

Различные категории.


У разных клиентов разные потребности, и хороший продавец найдет несколько способов продавать один и тот же товар. Рассмотрим продавца офисной мебели, который может продавать столы, стулья и шкафы для документов. Товары будут отнесены к их основной категории (например, Столы), но также могут быть сгруппированы по коллекции, бренду или стилю, каждая из которых является отдельной категорией в таксономии. Компании, внедряющие альтернативные таксономии, видят значительный рост продаж, но поддержка процесса добавляет сложности, которой лучше всего управлять в централизованной системе.

Повторные, дополнительные продажи и наборы товаров.


Связи товара с товаром (например, их взаимозаменяемость), продукта с категорией и категории с категорией обеспечивают интуитивно понятный процесс покупок, который может увеличить среднюю стоимость заказа (AOV) и пожизненную ценность клиента (LTVC). Эти связи должны быть введены в PIM для максимальной эффективности.

Поиск на сайте


Компании, использующие поисковые системы по сайту, просто должны иметь отличные данные, иначе поиск по сайту будет громоздким и бесполезным. Было отмечено, что компании, у которых реализован хороший поиск по сайту, конвертируют на 400% больше, чем те, кто этого не делает. Загрузите в свой поиск чистые, нормализованные данные из PIM и наблюдайте за ростом продаж!

Переводы на иностранные языки


Простой и эффективный метод создания и управления переводами информации о продуктах на иностранные языки имеет важное значение при выходе на международные рынки. PIM может облегчить этот процесс, предоставляя необходимые процессы для создания, просмотра и публикации вашего контента на иностранном языке.

Предупреждение: PIM система это не серебряная пуля


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

Без политик и контроля, касающихся информации о продукте, PIM система просто станет дорогостоящим новым хранилищем для тех же плохих данных.

Компании, планирующие внедрить PIM в свой стек электронной коммерции, должны создать план внедрения системы, в котором будет участвовать и бизнес и ИТ. Как минимум, они должны подумать над следующими вопросами:

  • Какие требования существуют к иерархиям? Какая иерархия будет основной и какие необходимы еще (по брендам или группам продуктов и т.д.)? Кто и как должен ими управлять?
  • Какие требования к качеству контента будут для разных каналов? Как эти требования доводятся до сведения продавцов, поставщиков и сторонних партнеров по контенту?
  • Потребуется ли доступ к PIM поставщикам или другим третьим сторонам? Как они будут добавлять новые продукты и обновлять существующие?
  • Какие отчеты и KPI будут управлять процессами обогащения продуктовой информации? Как измерить успех?


Ответы на эти вопросы очень важны для эффективного внедрения и использования PIM системы.

Благодаря тому, что PIM система работает отлаженно, компания вознаграждается эффективностью и масштабируемостью в доставке контента по каналам, которые зависят от качества информации о продукте, и она может сосредоточить свое внимание на оптимизации взаимодействия с пользователем для увеличения продаж и прибыльности.
Подробнее..

Зачем бизнесу внедрять PIM системы и как это сделать эффективно

26.02.2021 10:11:26 | Автор: admin

Эта статья основана на нашем опыте внедрения PIM системы OpenPIM.Эффективное управление информацией о товарах имеет решающее значение для любой организации. В течение многих лет электронные таблицы были инструментом управления данными по умолчанию, но по мере того, как компании расширяют свой каталог продуктов и выходят на большее количество каналов и рынков, ограничения электронных таблиц становятся очевидными. В результате все больше и больше предприятий внедряют PIM системы для управления информацией о своих продуктах.

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

1. Определите цели и объем вашего проекта PIM

Прежде чем внедрять PIM, определите основные бизнес-цели, которые вам необходимо достичь. Это важный шаг для определения ожиданий и определения того, как вы будете оценивать успех.

Вот несколько примеров целей, в достижении которых может помочь PIM:

  • Повышение клиентского опыта: предоставьте клиентам описания продуктов и изображения, которые вызывают необходимые эмоции и распространяйте их по всем каналам.

  • Повышение продуктивности маркетологов: вместо того, чтобы бороться с сотнями электронных таблиц, PIM предлагает эффективные процессы и удобный пользовательский интерфейс, чтобы сэкономить время и усилия при управлении каталогом продукции в различных каналах.

  • Повышение качества продуктовых данных: оптимизированные процессы и инструменты массового редактирования помогают обеспечить исчерпывающую, полную и безошибочную информацию о продукте по всем каналам.

  • Ускорение вывода на рынок: быстрее распространяйте новые продукты и контент по различным каналам, включая онлайн-магазины, мобильные платформы и многое другое.

  • Расширение каналов продаж: упростите процесс открытия новых каналов продаж, используя возможности вашей PIM для автоматического заполнения этих новых каналов информацией о продуктах.

  • Масштабирование в новые регионы: управление переводом и автоматизация конвертаций единиц измерения делают локализацию намного быстрее и эффективнее.

  • Упрощения взаимодействия с поставщиками: упростите процесс сбора информации о продуктах от поставщиков, позволив им легко загружать данные в любых форматах.

Затем вы можете начать думать о фазах вашего проекта. Стоит ли смоделировать весь каталог и начать управлять всеми своими продуктами с самого начала? Или вам следует начать с ограниченного подмножества ваших брендов, продуктов, каналов или регионов? Это решение будет зависеть от ваших бизнес-целей, а также от сложности и зрелости вашей организации.

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

С другой стороны, некоторым предприятиям более выгодно развертывание все сразу, чтобы получить централизованное управление все линейкой продуктов.

Независимо от подхода, убедитесь, что он соответствует вашим бизнес-целям, и задайте себе следующие вопросы:

  • Можем ли мы начать с подмножества продуктов или следует заняться всем каталогом?

  • Какие каналы наиболее важны для нашего бизнеса?

  • Является ли какой-либо регион более важным, чем другой?

  • Насколько важно время вывода на рынок для вашей компании?

2. Определите команду и процессы

После четкого определения общих бизнес-целей и области действия вы должны определить команду, которая будет работать над вашим проектом PIM, определить и распределить их роли, а также определить оптимальный процесс управления внедрением системы.

Определите, кто будет работать с PIM на ранней стадии процесса. В идеале эти люди должны иметь всесторонние знания о ваших продуктах, желаемой структуре каталога и потребностях вашего канала сбыта. PIM - это бизнес-приложение, предназначенное для обслуживания ваших команд, а не наоборот, поэтому вы должны обязательно определить людей, которые отвечают за управление информацией о продукте и которые получат выгоду от решения PIM.

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

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

3. Определите структуру вашего каталога

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

Распространенная ошибка организаций - начать использовать PIM как удобный интерфейс базы данных вместо того, чтобы использовать все его инструменты и функции. PIM - это больше, чем просто интерфейс для создания, чтения, обновления или удаления данных о товарах. PIM позволяет вам эффективно моделировать ваш каталог для всех ваших каналов и регионов.

Структура вашего каталога должна учитывать и поддерживать:

  • Категории продуктов, семейства, варианты и атрибуты продуктов в разбивке по различным каналам.

  • Атрибуты канала, такие как более короткие описания для мобильных приложений или большее количество изображений для сайтов электронной коммерции и маркетплейсов.

  • Атрибуты, зависящие от локали, такие как валюты и описания.

  • Определенные отношения и ассоциации между продуктами.

После того, как вы определили цели и объем своего проекта PIM, определили свою команду и заинтересованных лиц, а также определили структуру каталога, ваша следующая задача - собрать, стандартизировать и обогатить информацию о ваших продуктах.

4. Определите источники и соберите данные

Вам необходимо определить источники данных о продукте чтобы загружать все необходимые данные в PIM. Выбор правильных источников избавит от многих утомительных задач копирования и вставки, необходимых при работе с электронными таблицами.

Примите во внимание следующее:

  • Каковы ваши самые надежные источники?

  • Что будет источником каждой части данных о вашем продукте?

  • Какие источники содержат лучшие данные по определенным атрибутам?

  • Какие бывают форматы?

  • Могу ли я разрешить поставщикам предоставлять данные о товарах?

5. Автоматизируйте управление каталогом с помощью бизнес-правил и массовых действий

Одним из основных преимуществ PIM является множество функций автоматизации, которые ваша команда может использовать для искоренения утомительной и повторяющейся работы, позволяя им сосредоточиться на реальной работе.

Одним из примеров автоматизации PIM является использование механизма бизнес-правил для автоматического заполнения значений атрибутов, которые применяются ко многим продуктам и моделям продуктов. Это может привести к гораздо более высокому качеству данных за счет устранения человеческой ошибки, а также ускорения процесса обогащения.

Использование бизнес-правил позволяет автоматизировать такие действия, как:

  • Автоматическая категоризация новых продуктов по семейству.

  • Копирование значения из одного атрибута в другой.

  • Установка значения по умолчанию для пустого поля.

  • Назначение семейств на новые продукты.

Другой пример автоматизации PIM - использование массовых действий для одновременного выполнения действий со многими продуктами. Массовые действия упрощают выполнение множества задач, таких как редактирование и добавление значений атрибутов, изменение семейств, добавление продуктов и моделей продуктов в группы, добавление категорий и перемещение продуктов в разные категории, изменение родительского элемента продукта и добавление ассоциаций к выбору продуктов. Возможность массового добавления ассоциаций к выбору продуктов упрощает создание коллекций продуктов, позволяя группировать вместе все продукты, соответствующие выбранным критериям.

Вместо того, чтобы вручную выбирать товары на вкладках Excel и рисковать забыть товар или внести ошибки при публикации, бренды и ритейлеры должны автоматизировать процесс создания коллекций с помощью PIM. Предположим, ваше исследование показывает, что в этом сезоне коричневые куртки-бомберы стали очень популярны. Просто создайте индивидуальную коллекцию со словами коричневый, куртка-бомбер и мужчины, и все подходящие товары будут сгруппированы вместе. Более того, когда члены команды импортируют новые продукты, они автоматически добавляются в список, если соответствуют существующим критериям. Точно так же вы можете создавать ассоциации других связанных продуктов, чтобы создать возможности для перекрестных продаж - например, сопоставив коричневые кожаные перчатки с куртками-бомберами.

Статья получается довольно объемной, поэтому мы решили разбить ее на две части. Во второй части мы опишем следующие шаги внедрения PIM, такие как: валидацию и качество данных, экспорт данных и т.д.

Подробнее..

Как PIM может в 6 раз повысить конверсию интернет-магазина

24.07.2020 14:12:14 | Автор: admin
В прошлой статье я писал о том, как мы делали решение вокруг Akeneo, а пришли к собственному PIM. Один из выводов, который мы тогда сделали: PIM сам по себе не решает существующие проблемы e-commerce и нуждается в дополнительных сервисах, таких как DAM (Digital Asset Management), MDM (Master Data Management) и TCM (Transformations and Channels Management).

Часто MDM и DAM воспринимаются как отдельные системы, но в этой статье я предлагаю рассмотреть их как нераздельные части PIM, и показать, как они работают в связке.

PIM в e-commerce решает несколько больших проблем:

Проблема 1 систематизация каталогов;
Проблема 2 создание и хранение контента, при заведении товара на витрину;
Проблема 3 оптимизация процесса вывода нового товара на витрину, сокращение этого времени к минимуму.

Это то, над чем работают все вендоры PIM в мире. Нюанс в том, что сам по себе PIM (без MDM и DAM), эти проблемы решает лишь частично.

DAM это система для управления, организации, поиска, хранения и преобразования мультимедийных файлов. В PIM это своеобразная подсистема, где хранятся фото, видео, 3D обзоры товаров. Эти данные можно легко организовать, сделать их более портативными и легко доступными. Здесь все просто хранилище картинок и видео.

MDM (мастер-данные) в PIM это система управления точными исходными данными о товарах. Они содержат сегментацию продуктов, категоризацию, детализацию и другие детали.

У нас есть клиент, дистрибьютор, у которого сотни тысяч SKU. Эти товары хранятся на физическом складе. И все их нужно внести в систему, создав под каждый карточку товара. Пока эти карточки заполняются, товар пылится на складе, и бизнес терпит убытки. При этом у них даже есть какой-то свой PIM, но товаров много, и внесение их в систему занимает много времени. Элементарно, нельзя просто заменить картинку в карточке товара, нужно создавать новую. И так далее.

image

MDM в PIM это предзаполненные карточки товара. Звучит просто, но на деле это колоссальное облегчение работы и оптимизация временных затрат.

Возьмем стандартный маркетплейс. Без мастер-данных происходит следующее. Мерчант 1 добавил карточку товара iPhone красного цвета, а мерчант 2 добавил iPhone алого цвета. Система думает, что это два разных айфона, и продает SKU по-разному. В результате плодятся дубли, затрудняется аналитика и страдает скорость работы маркетплейса в целом.

Мастер-данные в PIM решают эту проблему. Когда первый из мерчантов создал карточку товара iPhone красный, он вносит в систему все его характеристики. Таким образом в системе появляются мастер-данные красного айфона. Затем, когда второй мерчант попытается ввести iPhone алый, система ему подскажет: Есть красный. Вы этот товар имеете в виду? Мерчант 2 нажимает Да, и тем самым подвязывает товар к мастер-данным, которые уже существуют в системе. Поставщик уже не заполняет 10 полей характеристик на товар, а фактически вводит только название и получает уже заполненную карточку.

Можно сказать по-другому, что предзаполненные карточки товара (MDM) это предустановленные наборы атрибутов для товара. Каким должен быть этот набор атрибутов? Это уже настраиваемая внутренняя логика системы. К примеру, у вас маркетплейс, и вы выставляете в настройках, что у модели телефона должен быть определенный набор атрибутов: размер экрана, память, батарея, размер коробки и пр.

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

image

Мастер-данные дают всю необходимую информацию для аналитики. Это можно сделать не только с помощью внешних подрядчиков, но и самостоятельно. Подключив, например, Power BI систему, можно получить крутые данные для аналитики:

Сделать прогноз продаж товара;
Понять сезонность;
Понять, как количество атрибутов влияет на продажи и прочее.

Я убежден, что PIM + DAM + MDM + TCM (преобразователи в разные каналы отображения контента) это будущее технологий для ритейла и e-commerce.

Мы сейчас завершаем большой проект с крупным DIY-ритейлером. Перевели его маркетплейс, сделанный на битриксе, на PIM платформы Scallium. Этот процесс сложный и длительный. Но уже показал результат. Провели А/В тест на витрине: 40% показов витрины, подвязанной к PIM Scallium, а 60% старая витрина. Визуально они ничем не отличаются для покупателя. Так вот, конверсия в новой витрине в 6 раз больше. Просто за счет того, что PIM быстрее обрабатывает данные, и, соответственно, пользователь видит более быструю витрину. На старой он ждет 3 секунды, и уходит. На новой витрине показатель отклика страницы составляет 500 миллисекунд.
Подробнее..

Почему учетная система не может заменить PIM в e-commerce

02.03.2021 18:23:53 | Автор: admin

Сравниваем функции управления контентом для e-commerce

Мой коллега Александр Злотко, Chief Revenue Officer Scallium, сравнил функции стандартной учетной системы и PIM-системы для товарного e-commerce проекта (к примеру, классического маркетплейса). Делюсь его анализом.

Профессиональные PIM-системы автоматизируют ключевые процедуры на всех этапах жизненного цикла товара:

  • Импорт первичных данных в процессе заведения нового товара;

  • Обогащение данными и поддержка в актуальном состоянии информации о товаре;

  • Экспорт информации о товарах в различные каналы продаж.

Когда речь идет о небольшом производстве и ограниченном ассортименте продукции, в качестве PIM могут использоваться различные бэк-офисные системы: учетная, ERP, CMS.

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

Почему? Потому что учетные системы и CMS изначально не были спроектированы для задач, которые должна решать PIM-система.

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

Задача

Учетная система/ERP

PIM-система

Создание новых карточек товаров

Нет возможности переиспользовать уже созданные атрибуты, их комбинации и группы для быстрого создания новых карточек.

Карточку для нового типа товара могут создать только программисты, что сильно замедляет процесс старта продаж новой категории товаров

Есть механизм атрибутов, групп атрибутов и наборов атрибутов.

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

Изменение существующих карточек товаров

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

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

Управление медиа-файлами (rich content)

Изначально не проектировалась для работы с тяжелыми медиа-файлами: картинки разных размеров и форматов, видео.

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

Процесс обновления медиа-файлов очень болезненный.

Используется специальное собственное хранилище S3, что обеспечивает быструю работу с медиа-файлами любого размера.

Кабинет мерчанта

Отсутствует интерфейс, с помощью которого внешние поставщики, производители могли бы загружать свои товары, модерировать контент, добавлять предложения (цены, остатки, параметры доставки)

Реализован полноценный личный кабинет для мерчанта, который включен в базовую поставку продукта PIM.

В кабинете мерчант может удобно импортировать файлы, используя популярные форматы (XLSX, YML) и легко выполнять мэппинг атрибутов в файле со структурой данных централизованного хранилища.

Также, реализована работа с форматами файлов для популярных маркетплейсов.

Например, если мерчант уже работает на Яндекс.Маркет, он сможет использовать тот же файл при импорте данных в PIM.

Мерчант может принимать участие в процессе модерации товаров и общаться с контент-менеджерами посредством встроенного чата.

Ролевая модель работы с товарами

Только с помощью программирования можно указать разные роли сотрудников, которые должны работать с товарами. Дать им определенные права доступа на объекты и операции.

Гибкий инструмент для построения ролевой модели данных. Определение прав доступа согласно должностным инструкциям.

Настройка процесса работы с товарами

Нельзя гибко настраивать этапы жизненного цикла товара, и что должно происходить на каждом из них.

Универсальный механизм настройки воркфлоу для разных объектов системы. С их помощью можно указать статусы объектов, возможные переходы, уведомления, настроить обязательность внесения какой-либо информации в атрибуты объекта.

Логирование, история изменений, распределение товаров в процессе модерации

Нет стандартного функционала мониторинга кто, когда и какие изменения вносил в карточку товара.

Нет возможности блокировать карточку товара, если его в данный момент модерирует кто-то из контент-менеджеров.

В процессе работы с большим объемом товаров важно отслеживать, кто и когда вносил изменения в карточку.

Если в описании товара обнаружена ошибка, всегда можно отследить, кто допустил эту ошибку и дать обратную связь сотруднику.

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

Работа с каналами продаж

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

Есть стандартные интерфейсы, с помощью которых можно интегрировать PIM с любой внешней системой (Rest API, интеграционная шина). Также, в коробочном продукте есть стандартные коннекторы к самым популярным маркетплейсам Украины и России.

Каждый новый релиз в текущем и следующем году будет обогащаться новыми коннекторами к маркетплейсам СНГ, Европы и США.

Работа с большим ассортиментом и большим количеством SKU

С ростом количества SKU в системе падает ее производительность.

Есть опыт хранения около 80 млн SKU и ежедневного обновления около 20 млн офферов (предложений).

Еще раз подчеркнем, что сравнение ни в коем случае не говорит о том, что какие-либо учетные системы недостаточно хороши. Просто они создавались под другие задачи. А управление товарным контентом это задача системы PIM.

Больше о технологиях PIM читайте в предыдущих материалах этого блога.

Подробнее..

Digital Asset Lifecycle

05.06.2021 10:15:16 | Автор: admin

С чего начать в управлении жизненным циклом цифровых активов и что это вообще такое?И ногие знакомы с понятием Управлен.

Сегодня я расскажу вам про методологию Управления жизненным циклом цифровых активов (Digital Asset Lifecycle), которая обычно включает в себя следующие этапы работы с креативами:

  1. Согласование идеи/ Аудит активов/ Оценка стоимости

  2. Приобретение / Создание креатива

  3. Согласование версий / Редактирование / Изменение

  4. Доставка / Публикация / Дистрибуция

  5. Хранение / Архивирование / Поиск

  6. Перепрофилирование / Повторное использование

  7. Вывод из эксплуатации

Согласование идеи/Аудит активов/ Оценка стоимости

Первым делом необходимо провести аудит ваших активов.Многие цифровые активы могут быть созданы из различных других лицензионных ресурсов. Например, PDF-файл - это цифровой актив. Он может содержать несколько лицензионных шрифтов и изображений, которые также являются активами.

Оценка позволяет дизайнерам и менеджерам лучше понять текущее состояние, потенциальную ценность и истинную стоимость нового цифрового актива.

Приобретение / Создание креатива

Тут все понятно. Вы закупаете креативы у другой команды или создаёте собственными силами.

Согласование версий / Редактирование / Изменение

Создание контента может быть многоэтапный и нелинейным процессом со множеством итераций и согласующий лиц. На данном этапе необходимо настроить ваш собственный рабочий процесс (workflow) чтобы в любой момент понимать на каком этапе создания находиться контент и кто ответственный.

Доставка / Публикация / Дистрибуция

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

Хранение / Архивирование / Поиск

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

Перепрофилирование / Повторное использование

Если последняя электронная книга, видео или PDF-файл, созданный вашей командой, была самой успешной, из ее выполнения можно извлечь уроки. Перепрофилирование и переработка существующего контента позволяет извлечь максимальную выгоду из ваших активов. Благодаря улучшенному отслеживанию и аналитике вы также можете определить, нужны ли вам новые изображения или шрифты, или действительны ли те же лицензии. Этот этап снижает затраты и увеличивает отдачу от ваших инвестиций в созданный контент.

Вывод из эксплуатации

После того, как вы извлекли максимальную ценность из вашего контента, приходит время чтобы списать его. Данный этап необходим для активов, которые используют устаревшие элементы бренда и дизайна, неактуальные слоганы и т.д. В отличие от этапов хранения и архивирования, на этапе вывода из эксплуатации удаляется контент из поисковой базы или коллекций для того чтобы никто не смог случайно его использовать для публикации или при создании нового контента. Ресурс по-прежнему доступен, но может храниться в отдельном месте и даже сжиматься для экономии места на жестких дисках.

Подробнее..
Категории: Контент-маркетинг , Pim , Romi , Dam

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru