Остались вопросы после вебинара или появились новые?
Задавай свои вопросы до 10 января 2021 года
Нажми "Ответить"
Данное мероприятие входит в серию совместных вебинаров Сообщества Cisco и Сетевой Академии Cisco.
Вебинар посвящен общему подходу к поиску и устранению неисправностей в multicast технологии. Василий Михайловский, эксперт Cisco, и Антон Носков, эксперт Сетевой Академии Cisco, повторят что такое multicast, рассмотрят типичные проблемы, с которыми сталкиваются клиенты, методы диагностики и шаги для предотвращения подобных проблем.
Программа мероприятия:
Информация об экспертах:
Василий Михайловский – работает в HTTS команде протоколов маршрутизации Центра технической поддержки (TAC) Cisco. Команда занимается поддержкой технологий: Interior Gateway Protocol (IGP), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS), multicast, multicast VPN (mVPN), intelligent WAN (iWAN), Quality of Service (QoS), Network Address Translation (NAT), Virtual Extensible LAN (VXLAN), Locator/ID Separation Protocol (LISP) и др. Опыт работы Василия в сфере сетевых технологий – более 16 лет, в качестве инженера Cisco TAC – более 5 лет. Обладает сертификатами Cisco CCIE, CCDE и Microsoft MCITP.
Антон Носков – один из ведущих инструкторов Сетевой Академии Cisco в России и инструктор Academy Support Center (ASC)/Instructor Training Center (ITC) на протяжении 15 лет. Руководитель инновационного центра "кибербезопасности и телекоммуникационных систем" Ярославского государственного технического университета.Обладает обширным набором сертификатов Cisco и других вендоров, а также дипломами Сетевой Академии.
Серия вебинаров Сообщества Cisco и Сетевой Академии Cisco:
Протокол OSPFv2 Глазами Cisco TAC: Типовые Проблемы, Ошибки Дизайна и Лучшие Практики
Добрый день.
В этих целях в Cisco Lab мы используем еще одно устройство Cisco как получатель и второе дополнительное как отправитель.
На интерфесе получателя нужна команда "ip igmp join-group <адрес мультикаст>"; отправка трафика командой "ping <адрес мультикаст> repeat 10000".
(некоторые версии требуют включать "ip multicast-routing" и pim интерфейсе, но тогда нужно добавить "ip pim dr-priority 0")
Можно также использовать CSR1K/ISRv/CSR8KV.
Для трафика на высоких скоростях используем IXIA.
Добрый день,
Я в своих лабах настраивал по этой инструкции:
Using VLC with Multicast and Unicast UDP Streams | AdvancedDigital Inc.
Работало без проблем. Попробуйте и если не заработает - буду рад помочь.
В каком месте можно посмотреть чёткое соответствие unicast ip и mcast ip? Во многих sh микс адресов unicast и mcast из-за чего нет понимания картины
Multicast адрес используется только как destination IP в заголовке IP-пакета. Этот адрес будет из диапазона 224.0.0.0/4
Unicast адреса в диапазоне 1.0.0.0 - 223.255.255.255, они будут в поле source IP заголовка IP-пакета.
Подскажите, какие могут быть нюансы при использовании VRRP (Virtual IP+Mac) на соседних устройствах?
Нюансов быть не должно при условии, что в данном сегменте находятся только конечные устройства и нет транзитных маршрутизаторов. Если транзитные маршрутизаторы есть, то будут проблемы с PIM если RPF указывает на VRRP адрес.
Такая же проблема и для HSRP - https://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_pim/configuration/15-2s/imc_hsrp_aware.html
Подскажите, на 9300 стык с оператором по PIM-SM (источник у оператора), ACL для фильтра лишнего мкаста на вход:
perm ip any 224.0.0.0/24;
perm ip any mgroup addr;
deny ip any 224.0.0.0/4;
perm ip any any.
При применении рушится PIM соседство, через время.Как будто 9300 не может фильтровать весь трафик по ACL, и зарубает 224.0.0.13. Возможно такое?
Если речь идет про Catalyst 9300, то для ограничения Multicast имеет смысл использовать "ip multicast boundary" конфигурацию, детали - https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-6/configuration_guide/ip_mcast_rtng/b_166_ip_mcast_rtng_9300_cg/configuring_basic_ip___multicast_routing.html
Если NX9K - то join-prune policy - https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/multicast/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Multicast_Routing_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Multicast_Routing_Configuration_Guide_chapt...
A router ACL applied on a Layer 3 physical or logical interface does not match multicast traffic. If multicast traffic must be blocked, use a PACL instead. This behavior applies to Cisco Nexus 9200, 9300, 9300-EX, and 9500 Series switches and Cisco Nexus 3164Q, 31128PQ, 3232C, and 3264Q switches.
Коллеги, столкнулся с интересной ситуацией. Мультикаст клиент подключен к сети как указано на схеме:
Когда клиент запрашивает мультикаст, то появляется трафик в направлении R1-SW1 (исходящий для R1), но также возникает трафик в направлении от SW1-R2 (входящий для R2), ровно в таком же количестве. Линки SW1-R1 и SW1-R2 находятся в одном vlan (поскольку используется HSRP) Роутеры R1, R2 видят себя через него как PIM соседи, DR один в сети. IGMP snooping на коммутаторе SW1 активирован для данного vlan. Коммутатор - это С3750X и он используется только как L2. В чем может быть дело?
Добрый день.
Кроме IGMP snooping, коммутатор также отслеживает порты на которых находятся PIM устройства.
Коммутатор справедливо полагает, что они также заинтересованы получать весь трафик мультикаст на сегменте даже если от них не были IGMP reports. Это ожидаемое поведение mrouter порт.
Если вы отключите PIM на R2, то трафик (через некоторое время) исчезнет.
Понятно. А есть какие-то альтернативные схемы подключения коммутатора к двум PIM маршрутизаторам. Основная задача - обеспечить резервирование. Спасибо.