Multicast Network Broadcast Configuration

[Translator]

  Good afternoon. There is a network on the Layer 2 and Layer 3 switches of the CISCO vendor, on the Layer 2 switches there are Hikvison IP cameras, on the L3 there is their gateway, and then the network of non-L3 switches connected to each other via OPSF. It is necessary to ensure the multicast broadcasting of these cameras to servers located several hops from the gateway of these cameras. 

  What was done - on the L3 swich on the next hop interfaces and the gateway, PIM Sparse mode was activated, a rendezvous point is indicated in the person of one of the IP interfaces of the extreme swich. Multicast was enabled on cameras previously working on Unicast and the address of the Groups from the range 225.1.1.0/24 was issued. IGMP Snooping was enabled on the Layer 2 switch. After that, neighboring layer 3 switches established a multicast neighborhood and in the output of the multicast groups studied, 2 groups were brought out - 224.0.1.40 and 239.255.255.250. Both are related to service protocols and are not groups to which cameras were issued. That is, if traffic from the cameras goes, then through a level 2 swich to level 3, for some reason it does not reach. The configuration of the cameras is very simple - you just need to specify the address of the group, turn on the multicast and reload the camera. Judging by the conclusion of the groups, the multicast on layer 3 switches works, but why then they do not study groups of cameras? Is there any additional configuration required on the Layer 2 switch other than Snoopinga over VLAN and interfaces that has already been done? What could be the problem?

[Flavio Miranda]

Hi

  Suggestion.  Using port span on the L2 switch, use a PC with Wireleshark and make sure the multcast traffic is reaching/leaving the camera.

Switch(config)#monitor session 1 source interface GigabitEthernet X
Switch(config)#monitor session 1 destination interface GigabitEthernet Y

connect a PC with Wireshark on GigabitEthernet Y and run the program.

You can also do the same on L3 switch.

[Translator]

The problem is that these switches are located far away, and I am in the main office and connect a laptop to them, you will need to go there. There are some other ways to check whether the multicast is traffic from the camera or not? In the output of the show interface command there is a multicast packet count, by this parameter can you determine whether the multicast works? In general, did I make any mistake in the configuration of the multicast on the switches or could I miss some command? 

By the way, I add that the Layer 3 switch, which is the gateway for cameras, is the 3750x model, and unlike its 3850 neighbor, which is RP, it does not accept the ip multicast-routing command. It only knows the ip multicast-routing distributed command. Is this a feature of this switch or is this a problem? 

[Translator]

Good afternoon,

There is one contradiction in your description. Namely:

далее сеть связанных друг с другом по OPSF таких не L3 коммутаторов

In order to support OSPF, they must have L3 functionality. So I guess these are still L3 switches.

It is very difficult to determine what and how is connected, because it is not clear for example what the "extreme sweatch" is. To try to understand, please provide a network diagram including cameras and where the rendezvous point is configured. Finally, one recommendation - range 225.0.0.0/24 is reserved. There is a multicast range that is analogous to the address range RFC1918, that is, locally unique. 239.0.0.0/8 Better use addresses from it.

Next, the question about the cameras is how the reception of flows is organized? Are they accepted by some centralized device? Do you have direct access to any part of the network equipment to perform diagnostics?

[Translator]

I'm described as not "such not," but "the same," that is, of course, L3. The diagram is attached. Now it was possible to check the cameras, traffic is coming from them. For some reason, switches do not study groups and requests. That is, IGMP does not work. As if somewhere there is a lack of some kind of team. 

There will be servers to accept traffic, but so far in the form of a test we want to request traffic up to one test PC. We query the traffic multicast using VLC, using the key with the password, login and unicast address of the camera. 

[Translator]

I see. Judging by the diagram, the gateway for the cameras is the VLAN interface? If so, then pim sparse mode should be enabled on it, as well as on the applique to the router.

If you have access, please show the command output

show ip pim interface
show ip mroute
show ip igmp group
show ip igmp interface

from the gateway. And from the access switch:

show igmp interface

Another important point is you said you were trying to get a stream using a unicast camera address. Show in more detail exactly how you are trying to do this.

[Translator · Accepted solution]

Yes, the VLAN interface on the left switch is the gateway for the cameras, and the right interface on the RP is the host. On them too PIM Szarse-mode prescribed. There is access to the equipment, but at the moment we were told that we need to add a couple more commands - the commands were added on the RP swich:

ip pim send-rp-announce Vlan600 scope 31

ip pim send-rp-discovery scope 31,

and most importantly, on the VLAN interface - the host gateway to which we will receive traffic from the camera, they prescribed the command:

ip igmp join-group 255.5.5.5

After that, everything worked. However, it did not become very clear to be honest)

I have not met any of these teams anywhere before, in the case of the 3rd, the question arises - will it really have to prescribe each group for this interface? And if there are hundreds or thousands? To the relevance of the first two, there are also questions - why do anonas, if all the pigs indicate what RP is?

And we connect to the camera like this: 

rtsp://admin:1q2w3e4r5t@10.34.5.2:554/Streaming/Channels/1/?transportmode=multicast

Hikvision Cameras

[Translator]

The send-rp-announce and send-rp-discovery commands are an automatic RP configuration method. In your case, if the RP has already been statically spelled out, they really were not necessary.

The ip igmp join-group command connects the sweatch itself in client mode of this group. This means that he himself will receive all the frames for this group and try to process them. I fear that if there are many groups, there will be a risk of CPU overloading with useless threads.

I understand that a camera only turns on a multicast stream after trying to connect via RTSP using the camera's unicast address? Can they broadcast the stream automatically?

[Translator]

It began to work after registering this Join command - before it, there was nothing in the studied groups except system multicasts of addresses. Is this a mandatory configuration command coming out? Without it will not work or can/desirably be done otherwise? Especially if it loads a swich. Apparently, there are many groups.

On account of the second, I do not know how to check this, since I do not have physical access to the camera switch. I was only able to check the multicast stream using Wireshark on my port. But this is after connecting to the camera using the above method. 

Everything is working at the moment, but I am not clear about the moment with Joinom, and also the moment that for each group you can create your own rendezvous point. It is not clear since in no command where it is declared, the address of the group to which it belongs is not specified. 

[Translator]

In general, the rendezvous point can be one for all groups. It is not necessary to configure them for each group separately, especially since in your topology it will be only one in any case.

I believe that it did not work because something was wrong with the IGMP configuration, but that it is difficult to say without output from the device.

[Translator]

Thank you!

[telcosetnwg]

Hello, Im also planning to switch the cameras mode from unicast to multicast. The client on different area on ospf than cameras. so I would like to see how you resolve the case . Could you share sh run without IPs so that I can catch sth for my configs.