Неоднозначность преобразования multicast IP-группы в mac-адрес и L2 свитч

Не так давно меня попросили разобраться в проблеме появления лишнего трафика на порту свитча Cisco 4924, к которому подключен преобразователь из IP-мультикаст в DVB-C или аналоговый сигнал (проще говоря, некая железка для организации услуги кабельного телевидения, не знаю точно чем она занимается). Схема включения включения выглядит так:

L2-multicast-scheme

Устройства MR1, MR2, MR3 – преобразователи IP multicast в КТВ-сигнал, далее просто потребители мультикаста. На порту Gi1/1 свитча sw1 по графику утилизации было примерно 110Мбит/с, а инженер, ответственный за оборудование MR1 утверждал, что он запрашивает мультикаста всего на 70Мбит/с, тем самым возник вопрос откуда взялось ещё 40Мбит/с трафика. Порты свитча Te1/29, Gi1/1, Gi1/2 включены в vlan 10, в vlan 10 igmp-snooping включен, таблица igmp-snooping содержит записи, ничего подозрительно замечено не было.

Поскольку оборудование sw1 находилось недалеко от живых людей, способных запустить wireshark, то было решено подключиться снифером к другому порту и отзеркалировать на него исходящий трафик с порта Gi1/1, после чего была получена статистика по 10000 пакетов (меню Statistics->Endpoints) (все адреса source и destination заменены для написания статьи, все совпадения случайны):

Wireshark-Statistics-Endpoints

Далее был получен комментарий ответственного за оборудование MR1, смысл которого сводился к тому, что группы 231.1.1.X не запрашиваются устройством MR1, они используются оборудованием, которое подключено к свитчу MR2. Вспомнив способ преобразования multicast IPv4 в mac-адрес и то, что свитч sw1 работает в режиме L2, причина проблемы сразу же стала понятна, destination mac у групп 230.1.1.X и 231.1.1.1.X одинаковые, а свитч коммутирует мультикаст-трафик не по IP-адресам, а по мак-адресам. Способ преобразования IP->mac описан в RFC1112(архив), наглядно изображено здесь(архив). Если кратко, то количество multicast IPv4 адресов 2^28, а количество multicast mac-адресов для IPv4 всего 2^23. В нашем случае 230.1.1.1 преобразуется в mac 0100.5e01.0101, в точно такой же мак преобразуется и адрес 231.1.1.1, а таблица коммутации мультикаст-трафика на sw1 при этом выглядит так:

sw1#show mac address-table multicast vlan 10               
Multicast Entries
 vlan    mac address     type    ports
-------+---------------+-------+--------------------------------------------
  10    0100.5e01.0101     igmp Gi1/1,Gi1/2,Te1/29
  10    0100.5e01.0102     igmp Gi1/1,Gi1/2,Te1/29
  10    0100.5e01.0103     igmp Gi1/1,Gi1/2,Te1/29
...

После замены адресов мультикаст-групп с 231.1.1.X на 231.10.10.X, проблема с лишним трафиком на порту Gi1/1 свитча sw1 была решена.

Если у вас используется L2 multicast switching, то при планировании мультикаст-адресации учитывайте преобразование IP->mac, описанное в RFC1112, а подключаясь к внешним источникам мультикаста проверяйте, не пересекаются ли новые мультикаст-группы с уже имеющимися в сети.

Advertisements

2 thoughts on “Неоднозначность преобразования multicast IP-группы в mac-адрес и L2 свитч

  1. rusnino

    Ну грабли довольно популярные, пока трафика не стало слишком много они и не замечали ничего, железки MR1-3 только частично впустую молотили…

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s