Yger

BFD может быть проблематичен в некоторых топологиях. Можно попробовать включить keepalive на SDP.

MPLS часть *A:PE1>config>router>mpls# ---------------------------------------------- path "default" no shutdown exit lsp-template "pmsi" p2mp default-path "default" cspf exit no shutdown exit Сервисная часть *A:PE1>config>service>vprn# info ---------------------------------------------- description "RSVP based I/S-PMS" <> mvpn auto-discovery default c-mcast-signaling bgp mdt-type sender-receiver provider-tunnel inclusive rsvp lsp-template "pmsi" no shutdown exit exit exit vrf-target unicast exit exit Ну и транзитные маршрутизаторы должны поддерживать P2MP LSP

Упрощенно говоря у вас следующая схема [Mcast Src]->R-VPLS->VPRN->LAG(sap)->Client Сигналлинг проходит успешно, но не работает Data Plane. Мультикаст начинает выходить из источника, но не доходит до VPRN (это видно из певой команды "Curr Fwding Rate : 0.0 kbps"). Как только поток начнет проходить через маршрутизатор вы увидите ненулевое значение. Основное подозрение - это R-VPLS, который не поддерживает мультикаст источники до определенного релиза (может 12R1 или 12R4). Релиз 11Rx точно не поддерживает это. Как вариант - переход на SAP вместо R-VPLS (проще) или апгрейд до более свежей версии (сложнее). Т.е. стоит попробовать такую схему сперва: [Mcast Src]->SAP->VPRN->LAG(sap)->Client Или такую [Mcast Src]->Spoke-SDP->VPRN->LAG(sap)->Client Мудрить с RSVP/LDP пока не стоит, т.к. нужно решить проблему доставки мультикаста до первого PE в вашей сети. По поводу многих муршрутизаторов в цепочке - вопрос сложный и простой одновременно: Все вопросы/ответы кроются в классическом построении сетей, где есть распределение на ядро (core) и границу (edge). Ядерные маршрутизаторы должны молотить и, в определенном плане, не сильно заботиться о Control Plane. Так что основная задача - это "разгрузить их мозги" и сделать клиентский траффик прозрачным для них. Это и решается с помощью VPRN (где скрыты пользовательские подсети и протоколы маршрутизации), VPLS (где скрываются MAC адреса пользователей и убирается STP), EVPN (продвинутая версия VPLS), xPIPE (где вообще скрывается практически все), так же всякие RSVP/LDP shortcats из этой оперы. С MVPN аналогичная история - не нужно ядерному маршрутизатору знать тысячи и десятки тысяч мультикастовых групп пользователей - нужно только уметь доставить траффик от одного PE до другого в туннеле. Туннелирование мультикаста опять может быть реализовано многими способами: классический PIM (Draft Rosen), mLDP или P2ML RSVP (ng-MVPN). Поэтому ответ на ваш вопрос "где нужен MVPN?" очень прост. Везде где есть IGMP клиенты нужен MVPN. Другой вопрос - нужен ли мне MVPN вообще? Многие операторы по старинке гонят все прямо через ядро, что выливается в повышенные требования к ядерным маршрутизаторам. Но если у вас пара групп, то воротить еще один уровень абстракции некоторые люди не хотят :) Если групп много, то конечно MVPN является хорошим выбором, т.к. помогает локализовать задачи. Могу сказать, что в новых сетях выбор падает не на PIM, а на mLDP или P2MP RSVP, причем mLDP популярнее, т.к. он проще (для понимания). Но поддержка mLDP должна быть на каждом маршрутизаторе!!!

День добрый! Я именно про мультикаст в RVPLS имею ввиду. Мне кажется, что мультикаст будет проходить в таком направлении VPRN->VPLS->client, но не будет проходить в обратную сторону Client->VPLS->VPRN

Не взлетать может по многим причинам: Проблема может быть в Control Plane (PIM, IGMP), так и в Data Plane (RVPLS, LAG, RPF, MTU и тп) Если ваш клиент подключен через L2 домен, тогда выяснить - доходит IGMP до вас или нет. debug router XXX igmp ... Есть ли соседство по PIM с вашим поставщиком? show router XXX pim neighbor Если IGMP получен и есть соседство по PIM, то уходит ли PIM Join в сторону вашего поставщика? debug router XXX pim ... Если уходит, то приходит ли что-то от него? Использование RVPLS не позволит посмотреть статистику приходящих пакетов в данном релизе. Могу предположить, что здесь и может быть затык. Не уверен, что источники мультикаста могут находиться в RVPLS. Т.е. может оказаться, что мультикаст может приходить только через SAP/spoke-SDP interface "SourceMulticast" create address 10.255.149.2/30 vpls "IPTV" <--- SAP? Так же проверить, что вы правиьную настройку "c-mcast-signaling bgp" используете и вам не нужно "c-mcast-signaling pim" Как вариант траблшутинга можно статически подписать одну из групп в сторону клиента (configure service vprn XXX igmp interface ClientVLC static group 224.0.90.1 starg) Затем глянуть на таблицу PIM на наличие (S,G) и (*,G) записей. show router XXX pim group Глянуть детальную статистику по группе: вход/исходящий интерфейс, скорость и тп show router XXX pim group <group> detail Ну и на последок - в вашей схеме сигнализация BGP не нужна, т.к. все происходит локально. Так же интейрфейс system не особо нужен внутри VPRN, хотя у вас могут быть и другие задачи. Так же желательно использовать уникальный route-distinguisher для каждого отдельного РЕ в рамках одного VPRN. Сообщения debug будут видны только в общем логе 99, но можно их и в сессию вывести configure log log-id 11 from debug-trace to session

День добрый! Требуется дополнительное пояснение к схеме. Насколько я понимаю - провайдер сливает вам (на ваш SR-7) мультикаст (здесь не важно с какого устройства) и вы хотите прогнать его по своей сети используя MVPN. Теперь у вас стоит задача настроить этот MVPN. Короткий ответ - вам нужно искать mvpn-ipv4 address family, т.к. в какой-то момент синтаксис изменился По большому счету вам нужно основательно почитать про устройство NG-MVPN с различными вариантами/комбинациями сигнализации (сразу скажу, что это не самое увлекательное чтиво :)). Могу предположить, что вы не выбрали вариант Draft Rosen, тогда с точки зрения BGP здесь опять может быть много вариантов. Лучше сразу активировать все доступные AF: family ipv4 vpn-ipv4 mvpn-ipv4 mcast-ipv4 <- важно указать ВСЕ используемые на вашей сети AF, а не только те которые хочется добавить. При этом BGP сессия пересигнализируется. Пример настройки VPRN I-PMSI = PIM Auto-Discovery = BGP C-Multicast signalling = PIM configure service vprn 100 interface "vlan100" create address 10.30.1.1/24 sap 1/1/2:100 create exit exit static-route 10.30.6.0/24 next-hop 10.30.1.2 pim interface "vlan100" exit rp static address 30.30.30.30 group-prefix 225.1.1.0/24 exit exit mvpn auto-discovery c-mcast-signaling pim provider-tunnel inclusive pim asm 239.0.0.30 exit exit exit vrf-target unicast exit exit Может так же подумать об обновлении ПО, если это возможно? Есть так же Advanced Configuration Guide, где можно найти примеры настроек различных технологий с подробным описанием и дебагингом.

Ключевое слово CPIPE. Два режима работы: SAToP и CESoPSN

У меня тоже нет такой информации под рукой в данный момент. Но в релизе 12.0.R15 такие карты возможно настроить. Так что 99% уверен, что поддержка еще сохранилась. Но вот для будущих релизов нужно внимательно смотреть на imm48-1gb-sfp, т.к. не уверен, что такая карта поддерживается *A:12.0.R15# configure card 1 card-type - card-type <card-type> - no card-type <card-type> : iom-20g|iom2-20g|iom-20g-b|iom3-xp|imm48-1gb-sfp| imm48-1gb-tx|imm8-10gb-xfp|imm4-10gb-xfp| imm5-10gb-xfp|imm1-oc768-tun|imm1-40gb-tun| imm1-100gb-cfp|imm12-10gb-sf+|iom3-xp-b| imm48-1gb-sfp-b|imm3-40gb-qsfp|iom3-xp-c|imm-1pac-fp3| imm-2pac-fp3|imm48-1gb-sfp-c

Это большой скачок в релизах :) Теоретически апгрейд возможен, но: Никакого ISSU конечно же Нужно проверить, что используемые карты еще поддерживаются в 12 релизе Нужно проверить, что используемые фичи не требуют новых обязательных параметров, иначе парсинг конфига может выпасть с ошибкой (все поправимо через встроенный vi, но просто занимает время). Нужно использовать "admin reboot upgrade" команду, чтобы принудительно перепрошить все fpga за раз. Думаю, что можно воспользоваться обычной процедурой апгрейда, которая подразумевает перезагрузку маршрутизатора. сделать бэкап конфига (мало ли откатиться надо будет) залить новый софт в новую директорию скопировать bootloader в корень cf3 поправить bof.cfg с указанием на новый софт перегрузить с командой выше проверить лог загрузки на ошибки конфига или еще чего проверить основные сервисы и доступность основных клентов

Действительно - моя информация устарела :) Сто лет не прикасался к данным железкам. NAT появился, вроде как, с 6.1 и только на определенном железе: SAR-H, SAR-Hc, SAR-Wx, SAR-8+csmv2+ограниченный список сетевых модулей, SAR-18. Настройки можно найти в "ROUTER CONFIGURATION GUIDE".

Добрый день! Не думаю, что это возможно. NAT реализуется с использованием спецального модуля, который работает только с 7750. Все таки 7705 нужно рассматривать как маршрутизатор агрегации ethernet и различных legacy подключений, а ему такой функционал не требуется в большинстве известных мне случаев.

Добрый день! Балансировка идет пропорционально весу, а вес каждого пути (path) расчитывается из настроенной скорости (bandwidth). Если у вас два пути с B1 и B2, то вес первого будет 100%*B1/(B1+B2), а второго будет соответствено 100%*B2/(B1+B2). Теперь во время принятия решения - каким путем послать пакет, будет учитываться этот коэффициент. При этом реальная нагрузка каждого flow при расчете пути, скорее всего, не берется, т.е. балансировка идет чисто per flow. В случае малого кол-ва потоков с существенно различающимися скоростями вы не увидите строго распределения, которого вы ожидаете по формуле. Но в случае многочисленных одинаковых потоков (1000+) вы конечно же приблизитесь к идеальному распределению. Кстати - bandwidth может передаваться в extended community, а это дает возможность принимать решение о балансировке на маршрутизаторах, отличных от тех, на которых настроен параметр bandwidth. Но и в этом случае кол-во сценариаев применения данной функции не так уж и велико.

rover-lt! Ну вот уже что-то по существу :) Я сейчас запустил аналогичную схему, и в моем случае связность между двумя алкателями присутствует (и пинг, и ISIS поднялся). GNS версия 1.2.3 под виндой. Никаких дополнительных настроек не делалось. Вы представили конфигурацию только с одного маршрутизатора - можно ли посмотреть, что настроено на втором? Состояние порта UP не означает, что сеществует реальная L2 связность между виртуальными алкателями. Порт в UP - это просто состояние vbridge в KVM.

Rover-lt. Описание проблемы достаточно скудное. Если требуется подсказка сообщества, то лучше описать схему и проблему(и условия тестирования) более подробно.

Теоретически такую полиси как у вас можно занчительно упростить. Можно даже обойтись простым default-action policy-statement "export.all" default-action accept exit exit Этот полиси тоже будет работать, если его использовать в vprn bgp export.