Не так давно меня попросили разобраться в проблеме появления лишнего трафика на порту свитча Cisco 4924, к которому подключен преобразователь из IP-мультикаст в DVB-C или аналоговый сигнал (проще говоря, некая железка для организации услуги кабельного телевидения, не знаю точно чем она занимается). Схема включения включения выглядит так:
Устройства 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 заменены для написания статьи, все совпадения случайны):
Далее был получен комментарий ответственного за оборудование 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, а подключаясь к внешним источникам мультикаста проверяйте, не пересекаются ли новые мультикаст-группы с уже имеющимися в сети.
Ну грабли довольно популярные, пока трафика не стало слишком много они и не замечали ничего, железки MR1-3 только частично впустую молотили…
Reblogged this on Silk road 2.0.