Протокол IP : Групповая IP-адресация

Руководство по устранению проблем многоадресной IP-рассылки

21 мая 2008 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Машинный перевод (28 июля 2013) | Английский (28 января 2008) | Отзыв

Содержание

Введение
Предварительные условия
      Требования
      Используемые компоненты
      Условные обозначения
Общие сведения
Маршрутизатор не пересылает на хост многоадресные пакеты по причине ошибки RPF
      Выявление ошибок
      Возможные способы решения проблемы
Маршрутизатор не пересылает на хост многоадресные пакеты из-за значения TTL, установленного у источника
      Выявление ошибок
      Возможные способы решения проблемы
Маршрутизатор не пересылает на хост многоадресные пакеты из-за порогового значения времени TTL, установленного на маршрутизаторе
      Выявление ошибок
      Возможные способы решения проблемы
Множественные равноценные пути приводят к нежелательному поведению обратного пути при продвижении данных
      Выявление ошибок
      Возможные способы решения проблемы
Почему при многоадресной IP-рассылке не выполняется балансировка нагрузки по всем имеющимся равноценным путям?
      Возможные способы решения проблемы
Почему маршрутизатор выдает сообщения об ошибках многоадресной рассылки "INVALID_RP_JOIN"?
      Выявление ошибок (часть 1)
      Выявление ошибок (часть 2)
Протокол CGMP не предотвращает возникновение потока многоадресных пакетов
      Выявление ошибок
      Проверки
      Возможные способы решения проблемы
Протокол CGMP не предотвращает затопление многоадресными пакетами из-за размещения источника/получателя.
      Выявление ошибок
      Возможные способы решения проблемы
Протокол CGMP не предотвращает возникновение потока многоадресных пакетов для некоторых групповых адресов
      Возможные способы решения проблемы
Связанные обсуждения сообщества поддержки Cisco
Дополнительная информация

Введение

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

Предварительные условия

Требования

Настоящий документ не содержит каких-либо специфических требований.

Используемые компоненты

Область применения настоящего документа не ограничивается какими-либо конкретными версиями аппаратного и программного обеспечения.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. в "Технические советы Cisco. Условные обозначения".

Общие сведения

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

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

Маршрутизатор не пересылает на хост многоадресные пакеты по причине ошибки RPF

В этом разделе предлагается решение общераспространенной проблемы многоадресной IP-рассылки, связанной со сбоем RPF. В качестве примера используется следующая диаграмма сети:

mcastguide1a.gif

На рисунке выше показано, что многоадресные пакеты поступают на интерфейс E0/0 маршрутизатора 75a. Пакеты поступают с сервера, имеющего IP-адрес 1.1.1.1 и выполняющего рассылку для группы 224.1.1.1. Это называется (S,G) или (1.1.1.1, 224.1.1.1).

Выявление ошибок

Хосты, подключенные непосредственно к маршрутизатору 75a, получают многоадресные пакеты, в то время как хосты, непосредственно подключенные к маршрутизатору 72a таких пакетов не получают. Сначала выполните команду show ip mroute 224.1.1.1 для того, чтобы посмотреть, что происходит на маршрутизаторе 75a. Эта команда произведет осмотр многоадресного маршрута для группового адреса 224.1.1.1:

75a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 

(1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 

Поскольку маршрутизатор работает в режиме уплотнения PIM (на это указывает флаг "D"), то мы не обращаем внимания на запись "*,G", а сосредотачиваемся на записи "S,G". Эта запись указывает на то, что источником многоадресных пакетов является сервер, который имеет адрес 1.1.1.1 и который выполняет рассылку на многоадресную группу 224.1.1.1. Пакеты рассылки поступают на интерфейс Ethernet0/0 и затем уходят с интерфейса Ethernet0/1. Это идеальный сценарий.

Выполните команду show ip pim neighbor, чтобы посмотреть, отображается ли восходящий маршрутизатор (75a) маршрутизатором 72a в качестве соседа PIM:

ip22-72a#show ip pim neighbor
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
2.1.1.1           Ethernet3/1        2d00h     00:01:15  v2 

Из листинга команды show ip pim neighbor видно, что с окружением PIM все в порядке.

Выполните команду show ip mroute, чтобы посмотреть, имеется ли у маршрутизатора 72a хороший многоадресный маршрут:

ip22-72a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
    Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
 
(1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags: 
  Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
    Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
 
ip22-72a#

Из листинга команды show ip mroute 224.1.1.1 мы видим, что входящим интерфейсом является интерфейс Ethernet2/0, в то время как это должен был бы быть интерфейс Etheret3/1.

Выполните команду show ip mroute 224.1.1.1 count, чтобы посмотреть, поступает ли на маршрутизатор 72а какой-нибудь многоадресный трафик для этой группы, а также узнать, что потом происходит с этим трафиком:

ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2032 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg      
Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null,
rate-limit etc)
                
Group: 224.1.1.1, Source count: 1, Packets forwarded:      0, Packets received: 471
  Source:      1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#

В строке Other counts мы видим, что трафик сбрасывается по причине сбоя RPF: total 471 drops, due to RPF failure – 471…

Выполните команду show ip rpf <source>, чтобы проверить, нет ли какой-нибудь ошибки RPF:

ip22-72a#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
  RPF interface: Ethernet2/0
  RPF neighbor: ? (0.0.0.0)
  RPF route/mask: 1.1.1.1/32
  RPF type: unicast (static)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
ip22-72a#

Программное обеспечение Cisco IOS® рассчитывает интерфейс RPF следующим образом. Возможные источники информации RPF: одноадресная таблица маршрутизации, таблица маршрутизации MBGP, таблица маршрутизации DVMRP и таблица статических многоадресных маршрутов. При расчете RPF интерфейса, для того чтобы определить, на каком источнике информации будет основываться расчет RPF, в основном используется административное расстояние. Конкретные правила таковы:

  • По всем предшествующим источникам данных RPF выполняется поиск на предмет совпадения с исходным IP-адресом. При использовании Разделяемых деревьев вместо исходного адреса используется адрес точки встречи (RP-адрес).

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

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

    1. Статические многоадресные маршруты

    2. Маршруты DVMRP

    3. Маршруты MBGP

    4. Одноадресные маршруты

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

Из листинга команды show ip rpf 1.1.1.1 видно, что интерфейсом RPF является интерфейс E2/0, однако входящим интерфейсом должен быть интерфейс E3/1.

Выполните команду show ip route 1.1.1.1, чтобы узнать, почему номер интерфейса RPF отличается от ожидаемого.

ip22-72a#show ip route 1.1.1.1
  Routing entry for 1.1.1.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet2/0
   Route metric is 0, traffic share count is 1

Из листинга команды show ip route 1.1.1.1 можно видеть, что существует статический маршрут /32, из-за которого был выбран ошибочный интерфейс RPF.

Выполните следующие отладочные команды:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

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

Примечание: процедура отладки пакетов представляет опасность. Данная процедура запускает коммутацию процессов для многоадресных пакетов, что приводит к увеличению загрузки ЦП. Кроме того, отладка пакетов может привести к возникновению больших объемов выходных данных, что в свою очередь может привести к полному зависанию маршрутизатора из-за медленного вывода данных на консольный порт. Перед отладкой пакетов обязательно надо отключить протоколирование в консоль и включить протоколирование в буферную память. Чтобы сделать это, выполните команды no logging console и logging buffered debugging. Результаты отладки можно посмотреть воспользовавшись командой show logging.

Возможные способы решения проблемы

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

ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1

Этот статический mroute формулирует, что для достижения адреса 1.1.1.1 для RPF в качестве адреса следующей ретрансляции необходимо использовать 2.1.1.1, являющийся внешним интерфейсом E3/1.

ip22-72a#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (2.1.1.1) 
  RPF route/mask: 1.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

Листинг команд show ip mroute и debug ip mpacket выглядит удовлетворительно. Количество отправленных пакетов, отображаемых счетчиком show ip mroute count, увеличивается. Хост А получает пакеты.

ip22-72a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 
    Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 

(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA 
  Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute 
  Outgoing interface list: 
    Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 

ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
 
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019
  Source: 1.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0
 
ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
 
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026
  Source: 1.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0
ip22-72a#
 

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward

Маршрутизатор не пересылает на хост многоадресные пакеты из-за значения TTL, установленного у источника

В этом разделе описывается решение распространенной проблемы, связанной с многоадресными пакетами IP, которые не были переданы из-за нулевого значения времени жизни (time to live – TTL). Это довольно распространенная проблема, поскольку существуют большое количество различных приложений, выполняющих многоадресную рассылку. Эти приложения в основном предназначены для использования в локальных сетях и в силу этого для них устанавливается низкое значение времени TTL, иногда это значение может быть равно 1. В качестве примера рассмотрим диаграмму сети, приведенную ниже:

mcastguide2a.gif

Выявление ошибок

На рисунке выше маршрутизатор A не пересылает пакеты, поступившие от источника S, на маршрутизатор В, к которому напрямую подключен Получатель (Receiver). Чтобы узнать состояние многоадресной маршрутизации, воспользуемся листингом команды show ip mroute, выполненной на маршрутизаторе A:

ROUTERA#show ip mroute 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 

(*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

Запись 224.0.1.40 можно оставить без внимания, поскольку все маршрутизаторы входят в состав этой группы Auto-RP Discovery. Однако для 224.1.1.1. в листинге не указано никакого источника. Помимо "*, 224.1.1.1", необходимо посмотреть "1.1.1.1, 224.1.1.1".

Выполните команду show ip rpf, чтобы узнать, не связано ли это со сбоем RPF:

ROUTERA#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet0/0 
  RPF neighbor: ? (0.0.0.0) - directly connected 
  RPF route/mask: 1.1.1.0/24 
  RPF type: unicast (connected) 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

Из приведенного выше листинга видно, что с RPF все в порядке. Проверка RPF корректно указывает на интерфейс E0/0, ведущий к IP-адресу источника.

Проверьте, настроен ли протокол PIM на интерфейсах. Для этого используйте команду show ip pim interface:

ROUTERA#show ip pim interface 

Address          Interface          Version/Mode    Nbr   Query     DR 
                                                    Count Intvl 
1.1.1.2          Ethernet0/0        v2/Sparse-Dense  0    30     1.1.1.2 
2.1.1.1          Ethernet0/1        v2/Sparse-Dense  2    30     2.1.1.2 

Листинг показывает, что с протоколом все в порядке. Проверьте, распознается ли активный трафик маршрутизатором. Для этого используйте команду show ip mroute active:

ROUTERA#show ip mroute active 
Active IP Multicast Sources - sending >= 4 kbps 

Из приведенного выше листинга видно, что маршрутизатор не распознает активный трафик.

ROUTERA#debug ip mpacket 
IP multicast packets debugging is on 

Вероятно, получатель не отправляет никаких IGMP-отчетов (вступлений) [Internet Group Management Protocol – протокол управления группами Интернета для группы 224.1.1.1. Это можно проверить выполнив команду show ip igmp group:

ROUTERB#show ip igmp group 
IGMP Connected Group Membership 
Group Address    Interface            Uptime    Expires   Last Reporter 
224.0.1.40       Ethernet1/1          00:34:34  never     2.1.1.2 
224.1.1.1        Ethernet1/2          00:30:02  00:02:45  3.1.1.2 

Для группы 224.1.1.1 имеется присоедиение (join) на интерфейсе E1/2. Это очень хорошо.

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

Можно проверить, не является ли это проблемой времени TTL. Для этого можно воспользоваться анализатором пакетов или выполнить команду show ip traffic:

ROUTERA#show ip traffic 
IP statistics: 
  Rcvd:  248756 total, 1185 local destination 
         0 format errors, 0 checksum errors, 63744 bad hop count 
         0 unknown protocol, 0 not a gateway 
         0 security failures, 0 bad options, 0 with options 

В приведенном выше листинге указано – "63744 bad hop counts". При каждом запуске этой команды это число увеличивается. Это серьезное указание на то, что отправитель отправляет пакеты, время TTL которых равно 1. Маршрутизатор А уменьшает это значение до 0. Это ведет к увеличению числа, указанного в поле "bad hop count".

Возможные способы решения проблемы

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

После этой операции состояние маршрутизатора А выглядит следующим образом:

ROUTERA#show ip mroute 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 

(*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 

(1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

Именно это нам и нужно.

На маршрутизаторе В можно видеть следующее:

ROUTERB#show ip mroute 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 

(*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 
    Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 

(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1 
  Outgoing interface list: 
    Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

Маршрутизатор не пересылает на хост многоадресные пакеты из-за порогового значения времени TTL, установленного на маршрутизаторе

В этом разделе предлагается решение широко распространенной проблемы, связанной с тем, что при низком значении порога TTL многоадресный трафик IP перестает поступать к получателю. В качестве примера используется следующая диаграмма сети:

mcastguide3a.gif

Выявление ошибок

На рисунке выше получатель (Receiver) не получает многоадресные пакеты, поступающие от источника (Source). Между источником и маршрутизатором 75а могут находиться несколько маршрутизаторов. Сначала проверим маршрутизатор 75a, поскольку он подключен непосредственно к получателю.

ip22-75a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 

(1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

Из приведенного выше листинга видно, что маршрутизатор 75a перенаправляет пакеты через исходящий интерфейс Ethernet0/1. Чтобы быть полностью уверенным в том, что маршрутизатор 75a перенаправляет пакеты, включите отладку (debug) для этого источника и для группы многоадресной рассылки:

ip22-75a#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1 
ip22-75a(config)#end 
ip22-75a#debug ip mpacket 101 
IP multicast packets debugging is on for access list 101 
ip22-75a# 
*Jan 17 09:04:08.714: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied 
*Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied 
*Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

Показанные выше отладочные сообщения указывают на то, что маршрутизатор 75a не перенаправляет многоадресные пакеты, потому что было достигнуто пороговое значение времени TTL. Можно проверить настройки маршрутизатора, чтобы найти причину этой неполадки. Итак, "виновник" найден:

interface Ethernet0/1 
 ip address 2.1.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 ip multicast ttl-threshold 15 

Пороговое значение TTL, установленное на маршрутизаторе, равняется 15. Однако это не означает, что пакеты, имеющие пороговое значение TTL выше 15, не могут отправляться. В действительности верно обратное. Приложение отправляется с пороговым значением TTL равным 15. К тому моменту, когда приложение достигает маршрутизатора 75a, значение TTL у многоадресных пакетов становится меньше 15.

Команда ip multicast ttl-threshold <value> означает, что любые пакеты, значение TTL у которых ниже указанного порога (в нашем случае это значение равно 15) перенаправляться не будут. Эта команда обычно используется, чтобы организовать "заграждение", которое не позволит внутреннему многоадресному трафику выйти за пределы внутренней сети.

Возможные способы решения проблемы

Можно "отключить" команду ip multicast ttl-threshold <value> указав аргумент no. В результате этого будет установлено значение TTL, используемое по умолчанию, – 0. Можно также уменьшить пороговое значение TTL таким образом, чтобы трафик начал проходить через маршрутизатор.

Множественные равноценные пути приводят к нежелательному поведению обратного пути при продвижении данных

В данном разделе описывается ситуация, при которой наличие множественных равноценных путей до источника может стать причиной нежелательного поведения функции переадресации в обратном направлении (Return Path Forwarding – RPF). Здесь также описано, как настроить многоадресную IP-рассылку таким образом, чтобы избежать такого режима работы. В качестве примера используется следующая диаграмма сети:

mcastguide4a.gif

Выявление ошибок

На рисунке выше показано, что у маршрутизатора 75b есть три равноценных обратных пути к источнику (1.1.1.1), и при этом маршрутизатор выбирает канал, который вы не предпочли бы выбрать первым в качестве канала RPF.

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

Возможные способы решения проблемы

Чтобы сменить интерфейс, который многоадресная IP-рассылка выбирает в качестве своего входящего интерфейса, можно выполнить одно из следующих действий:

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

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

  • Создайте статический многоадресный маршрут (mroute), который будет указывать на предпочтительный многоадресный интерфейс (это означает, что будет утрачена избыточность многоадресной рассылки).

В качестве примера создадим статический многоадресный маршрут.

Прежде чем устанавливать статический многоадресный маршрут, необходимо убедиться, что в приведенном ниже листинге таблица маршрутизации содержит три равноценных пути к исходному адресу 1.1.1.1. Информация RPF указывает, что RPF-интерфейсом является интерфейс E1/3:

ip22-75b#show ip route 1.1.1.1 
Routing entry for 1.1.1.0/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    3.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 
      Route metric is 20, traffic share count is 1 

ip22-75b#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet1/3 
  RPF neighbor: ? (4.1.1.1) 
  RPF route/mask: 1.1.1.0/24 
  RPF type: unicast (ospf 1) 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

ip22-75b#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 
    Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 
    Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 
    Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 

(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT 
  Incoming interface: Ethernet1/3, RPF nbr 4.1.1.1 
  Outgoing interface list: 
    Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 
    Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 
    Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

После настройки статического многоадресного маршрута в листинге можно видеть, что RPF-интерфейс поменялся на интерфейс E1/1:

ip22-75b#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 2.1.1.1 
ip22-75b(config)#end 

ip22-75b#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet1/1 
  RPF neighbor: ? (2.1.1.1) 
  RPF route/mask: 1.1.1.1/0 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

ip22-75b#show ip route 1.1.1.1 
Routing entry for 1.1.1.0/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    3.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 
      Route metric is 20, traffic share count is 1 

ip22-75b#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 
    Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 
    Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 
    Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 

(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT 
  Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1, Mroute 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 
    Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 
    Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

Почему при многоадресной IP-рассылке не выполняется балансировка нагрузки по всем имеющимся равноценным путям?

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

mcastguide4a.gif

На приведенном выше рисунке видно, что у маршрутизатора 75b имеются три равноценных обратных пути к источнику (1.1.1.1). Нам необходимо выполнить балансировку многоадресного трафика по всем трем каналам.

Возможные способы решения проблемы

В разделе Множественные равноценные пути приводят к нежелательному поведению обратного пути при продвижении данных мы узнали, что для проведения проверки RPF протокол PIM выбирает только один интерфейс, отсекая при этом все остальные интерфейсы. Это означает, что у нас не происходит балансировка нагрузки. Для балансировки нагрузки необходимо удалить PIM из избыточных каналов и создать туннель между маршрутизаторами 75a и 75b. Затем можно распределить нагрузку на уровне канала, а IP будет выполняться по туннелю.

Ниже приведены настройки туннеля:

Маршрутизатор 75a

интерфейс Tunnel0 
 ip address 6.1.1.1 255.255.255.0 
 ip pim  
 tunnel source Ethernet0/0 
 tunnel destination 5.1.1.1 
! 
interface Ethernet0/0 
 ip address 1.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 2.1.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 3.1.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 4.1.1.1 255.255.255.0

Маршрутизатор 75b

интерфейс Tunnel0 
 ip address 6.1.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 1.1.1.2 
! 
interface Ethernet1/1 
 ip address 2.1.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 3.1.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 4.1.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 5.1.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

После настройки туннеля выполните команду show ip mroute, чтобы посмотреть многоадресный маршрут (mroute) для данной группы:

ip22-75a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 

(1.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 

ip22-75b#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 
    Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 

(1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT 
  Incoming interface: Tunnel0, RPF nbr 6.1.1.1, Mroute 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

Чтобы убедиться в том, что многоадресные данные равномерно распределяются по всем трем каналам, проверьте интерфейсные данные маршрутизатора 75a.

Входящий интерфейс имеет пропускную способность 9000 бит/с:

ip22-75a#show interface e0/0 
. 
. 
  5 minute input rate 9000 bits/sec, 20 packets/sec 

Каждый из трех выходных интерфейсов показывает 3000 бит/с:

ip22-75a#show interface e0/1 
. 
. 
  5 minute output rate 3000 bits/sec, 7 packets/sec 

  
ip22-75a#show interface e0/2 
. 
. 
  5 minute output rate 3000 bits/sec, 7 packets/sec 


ip22-75a#show interface e0/3 
. 
. 
  5 minute output rate 3000 bits/sec, 7 packets/sec

Почему маршрутизатор выдает сообщения об ошибках многоадресной рассылки "INVALID_RP_JOIN"?

В этом разделе предлагается решение широко распространенной проблемы, связанной с сообщением об ошибке – "INVALID_RP_JOIN".

Выявление ошибок (часть 1)

Сообщение об этой ошибке поступает на точку встречи (Rendezvous Point – RP):

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) 
Join from 1.1.6.2 for invalid RP 1.1.5.4 
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) 
Join from 1.1.6.2 for invalid RP 1.1.5.4 

Причины этой ошибки описаны в справочнике Сообщения о системных ошибках программного обеспечения Cisco IOS Software: нисходящий PIM-маршрутизатор отправил для общего дерева сообщение о присоединении (join message), которое этот маршрутизатор отказывается принимать. Такое поведение говорит о том, что этот маршрутизатор разрешает присоединяться к конкретной точке встречи только нисходящим маршрутизаторам.

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

interface Ethernet0/0 
 ip address 1.1.5.4 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip pim accept-rp 10.2.2.2 8 
ip pim send-rp-announce Ethernet0/0 scope 15 
ip pim send-rp-discovery scope 15 
! 
access-list 8 permit 224.0.0.0 0.255.255.255 

Какую роль в приведенной выше конфигурации выполняет оператор accept-rp? В Документации CCO говорится, что "для настройки маршрутизатора на принятие запросов Join или Prune, предназначенных для указанной точки RP или конкретного списка групп, необходимо использовать команду глобальной настройки ip pim accept-rp". Чтобы снять этот флажок, используйте эту команду с аргументом no.

Когда команда ip pim accept-rp будет отключена, эти сообщения прекратятся. Итак, источник проблемы был найден. А как быть в том случае, если эта команда должна присутствовать в настройках? В этом случае вы можете разрешить использование ошибочного RP-адреса. Чтобы посмотреть правильный RP-адрес, выполните команду show ip pim rp mapping:

ip22-75a#show ip pim rp mapping 
PIM Group-to-RP Mappings 
This system is an RP (Auto-RP) 
This system is an RP-mapping agent 

Group(s) 224.0.0.0/4 
  RP 1.1.5.4 (?), v2v1 
    Info source: 1.1.5.4 (?), via Auto-RP 
         Uptime: 01:00:48, expires: 00:02:07

Согласно вышеприведенному листингу, адрес 1.1.5.4 - единственный RP-адрес, который был получен через Auto-RP или иным способом. Однако, данный маршрутизатор является единственной точкой встречи для групп 224.0.0.0/4. Таким образом, оператор pim accept-rp, указанный в конфигурации выше, является ошибочным.

Возможные способы решения проблемы

Необходимо исправить IP-адрес в операторе ip pim accept-rp следующим образом:

Измените данный оператор:

ip pim accept-rp 10.2.2.2 8

На следующее:

ip pim accept-rp 1.1.5.4 8

Оператор также можно изменить таким образом, чтобы он принимал то, что хранится в кэше auto-rp. При этом убедитесь, что в списке доступа (8 в этом примере) разрешен необходимый диапазон группы многоадресной рассылки. Приведем пример:

ip pim accept-rp auto-rp

access-list 8 permit 224.0.0.0 0.255.255.255

Выявление ошибок (часть 2)

Данное сообщение об ошибке выводится на маршрутизаторе 2.

router2#
*Aug 12 15:18:17.891:
      %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40)
      Join from  0.0.0.0 for invalid RP 2.1.1.1

Проверьте, является ли маршрутизатор 2 точкой встречи для группы 224.1.1.1:

router2#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:21:26, expires: 00:02:24
router2#

1.1.1.1 – точка встречи для 224.1.1.1.

Проверьте, является этот интерфейс одним из интерфейсов маршрутизатора 2:

router2#show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                1.1.1.2         YES NVRAM  up                    up      
Ethernet1/0                2.1.1.1         YES NVRAM  up                    up      
Ethernet2/0                unassigned      YES NVRAM  administratively down down    
router2#

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

router3#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:24:30, expires: 00:02:16
Group(s): 224.0.0.0/4, Static-Override
    RP: 2.1.1.1 (?)
router3#

Как видно, маршрутизатор 3 имеет статически настроенную информацию RP, указывающую на маршрутизатор 2, что неправильно. Теперь понятно, почему маршрутизатор 3 отправляет пакет RP-Join маршрутизатору 2.

Возможные способы решения проблемы

Можно настроить маршрутизатор 2 в качестве точки встречи для группы 224.1.1.1, а можно изменить настройки на маршрутизаторе 3 таким образом, чтобы он ссылался на корректный PR-адрес.

router3#show run | i rp
ip pim rp-address 2.1.1.1 override
router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router3(config)#no ip pim rp-address 2.1.1.1 override
router3(config)#exit
router3#

После соответствующего изменения настроек маршрутизатор 3 ссылается на корректный RP-адрес, а сообщение об ошибке больше не выводится.

router3#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:30:45, expires: 00:02:02
router3#

Протокол CGMP не предотвращает возникновение потока многоадресных пакетов

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

mcastguide7a.gif

Выявление ошибок

На рисунке выше в статической таблице CAM на маршрутизаторе Catalyst 5000 (Switch A) не указано ни одного правильного порта, которые были бы заняты. Маршрутизатор, выполняющий протокол CGMP, не отправляет пакетов CGMP.

Протокол CGMP был корректно настроен при помощи команды set cgmp enable на коммутаторе А и при помощи команды ip cgmp на интерфейсе E0/2 маршрутизатора 75a. Однако при выполнении команды show multicast group на коммутаторе А не отображается ни одной группы многоадресной рассылки:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 

Total Number of Entries = 0

В листинге этой команды должны быть указаны все порты, к которым подключен CGMP-маршрутизатор (port 2/3), а также все порты, к которым подключен заинтересованный получатель (port 2/6). Поскольку в последней строке листинга указан 0, мы можем предположить, что все порты необоснованно "затопляются" многоадресным трафиком, хотим мы этого или нет.

Проверки

Проверьте, имеются ли какие-нибудь PIM-соседи у маршрутизатора 75а:

ip22-75a#show ip pim neighbor 
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
2.1.1.1           Ethernet0/2        00:07:41  00:01:34  v2 

Из приведенного выше листинга видно, что маршрутизатор 75a видит маршрутизатор 75b (через коммутатор A) как действующего PIM-соседа.

Теперь проверим, получают ли эти маршрутизаторы корректную информацию о многоадресном маршруте (mroute):

ip22-75a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00 

(1.1.1.1, 224.1.1.1), 00:14:56/00:02:59, flags: CTA 
  Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00 

Из приведенного выше листинга видно, что маршрутизатор 75a перенаправляет пакеты через исходящий интерфейс Ethernet0/2 в сторону коммутатора А. В листинге, представленном ниже, мы видим, что маршрутизатор 75b получает многоадресные пакеты и корректно переадресует их:

ip22-75b#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00 
    Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00 

(1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/3, RPF nbr 2.1.1.2 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00 

Если посмотреть со стороны коммутатора А, то видно, что коммутатор видит маршрутизатор 75 со стороны порта 2/3.

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 

Total Number of Entries = 1 

Итак, до сих пор все было прекрасно. Выполним несколько отладочных команд на маршрутизаторе 75а. Может быть нам удастся что-нибудь выяснить:

ip22-75a#debug ip cgmp 
CGMP debugging is on 
*Feb  8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:45:22.206:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:46:22.234:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:47:22.262:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 

В приведенном выше листинге адрес 0000.0000.0000 является общегрупповым адресом, который используется в том случае, когда маршрутизаторы отправляют CGMP-сообщения Join/Leave с тем, чтобы коммутаторы могли занять их порты. В формате уровня МАС аббревиатура GDА означает Group Destination Address (адрес групп назначения), а аббревиатура USA означает Unicast Source Address (адрес источника одноадресной рассылки). Это адрес хоста, создавшего отчет IGMP, для которого генерируется это сообщение CGMP. В этом случае это – MAC-адрес для интерфейса E0/2 маршрутизатора 75a. MAC-адрес для интерфейса E0/2 на маршрутизаторе 75a можно посмотреть при помощи команды show interface:

ip22-75a#show interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)

Кроме того, при включении команды debug ip igmp можно иногда видеть следующее:

*Feb  8 12:51:41.854: IGMP: Received v2 Report from 2.1.1.3 (Ethernet0/2) for 224.1.1.1

Однако затем мы не видим соответствующий CGMP-пакет, поступивший с маршрутизатора 75а. Это означает, что маршрутизатор 75a получает отчеты IGMP, но не генерирует необходимые пакеты CGMP, содержащие информацию для коммутатора A о том, какие порты следует блокировать. А это именно то, что ожидается от маршрутизатора 75а как запросчика IGMP. Из листинга, полученного с маршрутизатора 75а, видно, почему этого не происходит:

ip22-75a#show ip igmp interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Internet address is 2.1.1.2/24 
  IGMP is enabled on interface 
  Current IGMP version is 2 
  CGMP is enabled 
  IGMP query interval is 60 seconds 
  IGMP querier timeout is 120 seconds 
  IGMP max query response time is 10 seconds 
  Last member query response interval is 1000 ms 
  Inbound IGMP access group is not set 
  IGMP activity: 3 joins, 1 leaves 
  Multicast routing is enabled on interface 
  Multicast TTL threshold is 0 
  Multicast designated router (DR) is 2.1.1.2 (this system) 
  IGMP querying router is 2.1.1.1 
  No multicast groups joined 

Если к одной подсети подключены два маршрутизатора и если они оба настроены на работу с протоколом CGMP, то только один из этих маршрутизаторов будет отправлять CGMP-пакеты. Маршрутизатор, отправляющий CGMP-пакеты, является запрашивающим IGMP-маршрутизатором. Такой маршрутизатор представляет собой маршрутизатор с наименьшим значением IP-адреса из всех маршрутизаторов, на которых включен протокол IGMP.

В нашем случае IGMP включен как на маршрутизаторе 75а, так и на маршрутизаторе 75b (последний становится опрашивающим IGMP-маршрутизатором). Однако протокол CGMP включен только на маршрутизаторе 75a. Поскольку маршрутизатор 75а не является опрашивающим IGMP-маршрутизатором, никакие CGMP-пакеты не отправляются.

Возможные способы решения проблемы

Чтобы устранить эту проблему, на запрашивающем IGMP-маршрутизаторе необходимо настроить протокол CGMP. В нашем случае это маршрутизатор 75b. Сначала на маршрутизаторе 75b необходимо выполнить отладочные команды:

ip22-75b#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75b(config)#int e 1/3 
ip22-75b(config-if)#ip cgmp 
ip22-75b(config-if)#end 
ip22-75b#debug ip cgmp 
ip22-75b#debug ip igmp 
*Feb  8 12:58:42.422: IGMP: Received v2 Report from 2.1.1.3 (Ethernet1/3) for 224.1.1.1 
*Feb  8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 
*Feb  8 12:58:42.422:       from 2.1.1.3 for 224.1.1.1 
*Feb  8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 
*Feb  8 12:58:42.422:       GDA 0100.5e01.0101, USA 0030.b655.a859 

Маршрутизатор 75b получает от 2.1.1.3 отчет IGMP для группы 224.1.1.1. Затем он отправляет CGMP-сообщение Join на коммутатор A для MAC-эквивалента 224.1.1.1 с MAC-адресом (USA) заинтересованного хоста 2.1.1.3. Коммутатор A определяет, какой порт включен на хосте, поэтому помечает его как открытый и блокирует другие порты.

Теперь на коммутаторе А все должно работать нормально:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4,2/6 

Total Number of Entries = 2 

Так значительно лучше. На коммутаторе А пакеты 224.1.1.1 (01-00-5e-01-01-01) отправляются только с портов 2/3, 2/4 и 2/6, как это и должно быть. Затопление остальных портов прекратилось. Теперь общее количество записей указано правильно – 2 записи. МАС-адрес 01-00-5e-00-01-28 отображен из адреса многоадресной рассылки 224.0.1.40, который используется для CGMP-сообщений о рефлексивном присоединении (self joins).

Протокол CGMP не предотвращает затопление многоадресными пакетами из-за размещения источника/получателя.

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

mcastguide8a.gif

Выявление ошибок

На рисунке сверху маршрутизаторы Router 75a и Router 75b, а также коммутатор Catalyst 5000 (Switch A) правильно настроены для многоадресной передачи данных и использования протокола CGMP. На хост поступает многоадресный трафик. Однако, этот трафик получают и все другие хосты, находящиеся со стороны коммутатора А. Коммутатор А выполняет лавинную маршрутизацию трафика через все порты. Это указывает на то, что протокол CGMP не работает.

Листинг команды show multicast group, выполненной на коммутаторе A, выглядит следующим образом:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 

Total Number of Entries = 1 

Из приведенного выше листинга видно, что единственной группой является группа 224.0.1.40, которая используется маршрутизатором в момент, когда он отправляет CGMP-сообщения о рефлексивном присоединении для группы auto-RP. Почему случилось так, что нет никаких других групп?

Возможные способы решения проблемы

Чтобы найти решение, необходимо понимать, каким образом протокол CGMP ведет себя при определенных обстоятельствах. Маршрутизатор с включенным CGMP отправляет на коммутатор CGMP-сообщения о присоединении, информируя этот коммутатор о хостах, заинтересованных в конкретной группе многоадресной рассылки. Для этих хостов коммутатор осуществляет поиск MAC-адресов в таблице CAM, а затем пересылает многоадресные пакеты через порты соответствующих хостов и блокирует переадресацию многоадресных пакетов через остальные порты.

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

Например, если бы источник находился на той же подсети (VLAN), 2.1.1.0/24, как и маршрутизаторы 75a и 75b, то CGMP работал бы так как надо. Маршрутизатор, получив сведения о пакетах из источника, отправит коммутатору CGMP-сообщение о рефлексивном присоединении, который динамически определит, на каких портах находится маршрутизатор, а затем заблокирует пересылку многоадресных пакетов через все другие порты.

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

Другой пример: у нас имеется заинтересованный хост в той же самой VLAN. В этом случае при получении CGMP-маршрутизатором IGMP-отчета от хоста, который заинтересован в конкретной группе многоадресной рассылки, этот маршрутизатор отправил бы CGMP-сообщение о присоединении. В этом сообщении был бы указан МАС-адрес хоста, который хочет присоединиться, и группа, к которой он хочет присоединиться. Затем Catalyst 5000 осуществит проверку таблицы CAM для MAC-адресов хостов, поместит ассоциированный порт в список многоадресной группы и заблокирует все остальные незаинтересованные порты.

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

Чтобы протокол CGMP работал в транзитной сети, можно добавить хост к той же VLAN, к которой добавлены маршрутизаторы 75a и 75b, как показано на следующей схеме.

mcastguide8b.gif

Или переместите источник на ту же подсеть, на которой находятся маршрутизаторы 75a и 75b, как в этом примере.

mcastguide8c.gif

Переместите источник в ту же самую подсеть и затем проверьте листинг с коммутатора А:

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 
 2/4       6 

Total Number of Entries = 2 
'*' - Configured 
Console> (enable) 

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4 

Total Number of Entries = 2 

Теперь на коммутаторе А адрес 224.1.1.1 (01-00-5e-01-01-01) отправляется только на порты маршрутизаторов 2/3 и 2/4 (а не на все порты, находящиеся от коммутатора А).

Протокол CGMP не предотвращает возникновение потока многоадресных пакетов для некоторых групповых адресов

В данном разделе рассматриваются причины, по которым некоторые групповые IP-адреса заставляют протокол группового управления Cisco (CGMP) высылать многоадресный трафик на все порты в локальной сети. При использовании группового адреса 225.0.0.1 протокол CGMP не работает. Он пересылает многоадресный поток через всех порты коммутатора и бесполезно расходует пропускную способность. Однако если изменить адрес на 225.1.1.1, то CGMP будет работать так как надо. Что же не так с адресом 225.0.0.1, ведь он не является зарегистрированным адресом для протокола маршрутизации?

Возможные способы решения проблемы

Во-первых, важно представлять себе, каким образом адреса многоадресной рассылки 3-го уровня отображаются на адреса многоадресной рассылки 2-го уровня. Все кадры многоадресной IP-рассылки используют адреса уровня IEEE Media Access Control (MAC), начинающиеся с 24-битного префикса 0x0100.5e. При отображении адресов 3-го уровня на адреса 2-го уровня, 23 бита низкого порядка адреса многоадресной рассылки 3-го уровня отображаются на 23 бита низкого порядка MAC-адреса IEEE.

Необходимо также знать, что для IP-адреса многоадресной рассылки имеются 28 бит уникального адресного пространства (32 бита минус 4 бита, относящихся к префиксу класса D – 1110). Поскольку имеется только 23 бита, отображенных в адресе IEEE MAC, то остается 5 бит перекрытия. Это означает, что несколько адресов многоадресной рассылки 3-го уровня могут быть сопоставлены с одним адресом многоадресной рассылки 2-го уровня.

Например:

224.0.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary
low order 23 bits =    000 0000.0000 0000.0000 0001
hex equivalent    =     0    0    0    0    0    1
result of mapping = 0x0100.5e00.0001


224.128.0.1 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary
low order 23 bits =      000 0000.0000 0000.0000 0001
hex equivalent    =       0    0    0     0    0    1
result of mapping = 0x0100.5e00.0001

Обратите внимание, что в приведенном выше примере и адрес 224.0.0.1, и адрес 224.128.0.1 отображаются на один и тот же адрес многоадресной рассылки 2-го уровня.

Теперь когда нам известно, каким образом сопоставляются адреса многоадресной рассылки уровня 2 и уровня 3, мы попробуем найти решение указанной проблемы.

Коммутатор А направляет поток многоадресных пакетов на 224.0.0.x, потому что эти адреса являются локальными адресами канала, и нам необходимо убедиться, что локальные адреса канала попадают ко всем устройствам, находящимся в LAN. Коммутаторы Catalyst также направляют многоадресные пакеты на другие адреса многоадресной рассылки, которые на MAC-уровне сопоставлены неоднозначно с адресом 224.0.0.x (например, адрес 224.0.0.1 и адрес 225.0.0.1 оба сопоставляются с адресом 0100.5e00.0001). Коммутатор передает многоадресные пакеты, предназначенные для этих локальных адресов канала, независимо от того, включен CGMP или нет.

Следовательно, приложение многоадресной рассылки должно избегать использования адресов класса D, которые сопоставляются с адресом многоадресной рассылки 2-го уровня – 0100.5e00.00xx, где xx – шестнадцатеричное число от 00 до FF. Сюда входят следующие адреса класса D:

224.0.0.x (x = 0 to 255)
225.0.0.x 
.
239.0.0.x


224.128.0.x (x = 0 to 255)
225.128.0.x
.
239.128.0.x

Связанные обсуждения сообщества поддержки Cisco

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


Дополнительная информация


Document ID: 16450