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

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

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


Содержание


Введение

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

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

Требования

Для этого документа отсутствуют особые требования.

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

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

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

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

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

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

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

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-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. Эта команда произведет осмотр многоадресного маршрута (mroute) для группового адреса 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 хороший многоадресный маршрут (mroute):

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: общее 471 отбрасывание, из-за Ошибки переадресации по обратному пути – 471 …

Выполните команду <source> show ip rpf, чтобы видеть, существует ли ошибка 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. Статические mroute

    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.

Возможные методы настройки

Можно или изменить таблицу одноадресной маршрутизации для удовлетворения этого требования, или можно добавить статическое mroute для принуждения групповой адресации к 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-пакетами, которые не были переданы из-за нулевого значения срока жизни (TTL). Это довольно распространенная проблема, поскольку существуют большое количество различных приложений, выполняющих многоадресную рассылку. Эти приложения в основном предназначены для использования в локальных сетях и в силу этого для них устанавливается низкое значение времени TTL, иногда это значение может быть равно 1. В качестве примера рассмотрим диаграмму сети, приведенную ниже..

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide2a.gif

Диагностика неисправности

На рисунке выше, Маршрутизатор A не делает передач пакетов из источника (S) к приемнику с прямым подключением B Маршрутизатора. Чтобы узнать состояние многоадресной маршрутизации, воспользуемся листингом команды 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 – это протокол переполнения и отсечения, поэтому соединения отсутствуют, но имеются наращивания. Поскольку маршрутизатор В не получил потока от маршрутизатора А, он не знает, куда следует отправлять наращивание.

Можно проверить, не является ли это проблемой времени 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 перестает поступать к получателю. В качестве примера используется следующая диаграмма сети.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide3a.gif

Диагностика неисправности

На рисунке выше, Получатель не получает пакеты групповой адресации от Источника. Между источником и маршрутизатором 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.

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

Возможные методы настройки

Или удалите команду <value> ip multicast ttl-threshold при помощи этой команды с параметром no, которая возвращается к значению порога TTL по умолчанию 0, или понизьте порог TTL так, чтобы мог пройти трафик.

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide4a.gif

Диагностика неисправности

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

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

Возможные методы настройки

Изменить интерфейсную групповую 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-рассылки с распределением нагрузки по всем доступным путям одинаковой стоимости. В качестве примера используется следующая диаграмма сети.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide4a.gif

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

Возможные методы настройки

Как вы видели в Результате Множественных равноценных путей в разделе Нежелательного изменения обратного пути выше, независимая от протокола многоадресная передача (PIM) только выбирает один интерфейс для проверки Return Path Forwarding (RPF) и сокращает другие. Это означает, что у нас не происходит балансировка нагрузки. Для распределения нагрузки необходимо удалить PIM из избыточных каналов и создать туннель между маршрутизаторами Router 75a и Router 75b. Затем можно распределить нагрузку на уровне канала и IP выполняется через туннель.

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

Маршрутизатор 75a
interface Tunnel0 
 ip address 6.1.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 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
interface Tunnel0 
 ip address 6.1.1.2 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

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

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

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

Сообщение об этой ошибке поступает на точку встречи (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 показывают, из-за чего происходит эта ошибка: нисходящий 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? В Командах Маршрутизации групповой IP-адресации этот документ сообщает, "для настройки маршрутизатора для принятия Соединений или Слив, предназначенных для указанного 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.

Возможные методы настройки

Или сделайте router2 RP для группы 224.1.1.1 или измените конфигурацию на router3, таким образом, это обращается к корректному адресу RP.

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) включен лишь на некоторых маршрутизаторах конкретной подсети, а также рассказывается о том, как можно избежать возникновения этой проблемы. В качестве примера используется следующая диаграмма сети.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide7a.gif

Диагностика неисправности

На рисунке выше, статическая таблица CAM в Коммутаторе Catalyst 5000 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) на Маршрутизаторе 75a:

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 как допустимого соседа PIM через коммутатор A.

Теперь проверьте, получаете ли вы корректный многоадресный маршрут (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-пакеты не отправляются.

Возможные методы настройки

Для решения проблемы необходимо настроить CGMP на Маршрутизаторе запросов IGMP. В нашем случае это маршрутизатор 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 получает отчет IGMP от 2.1.1.3 для группы 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-сообщений о рефлексивном присоединении.

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-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 self-join, который динамически определит, на каких портах находится маршрутизатор, и заблокирует пересылку многоадресных пакетов через все другие порты.

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

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

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8b.gif

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-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, которые сопоставляются с адресом многоадресной рассылки второго уровня 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

Получены двойные потоки Пакета групповой адресации

Причина 1

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

Возможное исправление 1

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

Причина 2

Эта проблема может произойти в Cisco Catalyst 6500 коммутаторов, которые настроены для выходного режима репликации групповой адресации и могут быть вызваны удалением и повторной вставкой любых линейных карт [OIR]. После OIR Порт матрицы выхода [FPOE] может быть misprogrammed, который может заставить пакеты быть направленными к неправильному Оптоволоконному выходному каналу и переданными неправильным линейным платам. Результат состоит в том, что они циклично выполнены назад к Матрице и реплицированы многократно, когда они выходят на корректной линейной плате.

C6509#show mls ip multicast capability
Current mode of replication is Egress
Auto replication mode detection is ON

 Slot           Multicast replication capability
    1                        Egress
    2                        Egress
    3                        Egress
    4                        Egress
    5                        Egress
    6                        Egress
    7                        Egress

Возможное исправление 2

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

mls ip multicast replication-mode ingress

Обновите программное обеспечение Cisco IOS к выпуску, на который не влияет идентификатор ошибки Cisco CSCeg28814 (только зарегистрированные клиенты), чтобы к permanantly решают вопрос.

Причина 3

Если значение Масштабирования стороны получения [RSS], на конечных узлах или серверах, отключено, эта проблема может также произойти.

Возможное исправление 3

Значение RSS упрощает более быструю передачу данных по множественным ЦПУ. Включите значение RSS на конечном узле или сервере. FRefer к статье microsoft Масштабируемые Сети с RSS leavingcisco.com для получения дополнительной информации.

Почему Отброшены Пакеты групповой адресации?

Причина 1

Возможно, что вы видите чрезмерные сбросы, и входящий пакет понижается на интерфейсе (ах), когда течет Многоадресный трафик. Можно проверить сбросы с командой show interface.

Switch#show interface gi 1/0


!--- Output suppressed


MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is SX
  input flow-control is off, output flow-control is on 
  Clock mode is auto
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 195000 bits/sec, 85 packets/sec
  30 second output rate 1000 bits/sec, 1 packets/sec
  L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes
  L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt, 438000092206 bytes mcast
  L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes
     1326976857 packets input, 506833655045 bytes, 0 no buffer
     Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     31643944 packets output, 3124494549 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Возможное исправление 1

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

Настройте это:

Switch(config-if)#ip pim spt-threshold infinity

Причина 2

При использовании команды ip igmp join-group <group-name> на любом интерфейсе (ах) она делает коммутацию в контексте процесса. Если пакеты групповой адресации являются процессом, включил любой интерфейс (ы), он использует больше ЦПУ, поскольку он передает под мандат коммутацию в контексте процесса всех пакетов той группе. Можно всем заправлять буферная команда input-interface и проверить аварийный размер.

Switch#show buffers input-interface gi 1/0

  Header DataArea  Pool Rcnt  Size Link  Enc    Flags          Input      Output

437C6EAC  8096AE4 Middl    1   434    7    1      280          Gi1/1        None
437C74B4  8097864 Middl    1   298    7    1      280          Gi1/1        None
437C98E4  809C964 Middl    1   434    7    1      280          Gi1/1        None
437CAAFC  809F1E4 Middl    1   349    7    1      280          Gi1/1        None
437CAE00  809F8A4 Middl    1   519    7    1      280          Gi1/1        None


!--- Output suppressed

Возможное исправление 2

Можно использовать команду ip igmp static-group <group-name> вместо команды ip igmp join-group <group-name>.

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

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

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


Дополнительные сведения


Document ID: 16450