Entry type: FAQ, Entry ID: 9822272, Entry date: 10/29/2004

Procedure and meaning of multicast connections with Industrial Ethernet CPs

  • Entry
  • Associated product(s)

What should you watch out for when using multicast connections and how are they configured?

Multicast is a special connection option that with Industrial Ethernet CPs is only supported or can only be configured with UDP connections (UDP = User Datagram Protocol). There is often the wish to send a message from one station to multiple partner stations. The important thing here is that the messages are sent simultaneously and are received almost simultaneously by the partner stations. Sending and receiving of broadcast messages is therefore always demanded. In the case of a broadcast message, the message is really received by all the stations on the network. Broadcast messages are also needed, for example, for finding an MAC address to an IP address (ARP request). Therefore a communications module must always accept broadcast telegrams and evaluate them with an appropriate software. If there are too many broadcast messages in the network, the network performance drops. This is because the individual modules have to process all the broadcast telegrams to ascertain whether or not they are meant for them.

The following 2 points are to be noted for Industrial Ethernet CPs with regard to broadcast:

  • In all Industrial Ethernet CPs the broadcast messages are filtered out as high priority upon receipt. All messages that are not messages that can be used (e.g. ARP Request) are discarded immediately. This prevents the negative influence of broadcast messages on the other connections.
  • Modules that cannot receive any broadcast messages, can however be used to send broadcast messages into the network.

To ensure a synchronous sending of a message to multiple station, the connection option "Multicast" has been introduced. By means of a definition (via configuration as of SIMATIC STEP7/ NCM V5.1 + SP2), reserved Multicast partners are enabled to send a message directed to a certain number of communication partners.

Behavior of the communications processor:

The communications processor is usually also locked for multicast messages. One exception is the time. If a multicast group is now activated in the configuration, it is also activated in the LAN controller. Only this one particular group is activated and the communications processor continues to be impervious to broadcast messages from the network. Each multicast group configured must be noted in the LAN controller.
This is why multicast is always the better solution when messages are to be sent to groups of partner stations.

  • You can configure up to 48 multicast groups in one communications processor.
  • The data length is limited to 2048 bytes as for UDP.
  • The communications processor continues to be impervious to broadcast loads.
  • Requirement is of course that all partner stations also support multicast.
  • The messages are sent without any security mechanism (acknowledgment).

The messages are sent without acknowledgment, because there is no provision for acknowledgments in the UDP protocol. An acknowledgment could cause problems if, for example, a message is sent to 100 partners, then 100 acknowledgments (one per partner) would arrive at the same time. Such a surge of data could not be evaluated by the sender module.

Configuring multicast connections:

  1. Creating a connection in NETPRO:
    As usual the multicast connection can be created using the standard dialog. A UDP connection is selected as Connection Type and "All multicast stations" as Connection Partner (see figure below):

Figure 1: Integration of a new connection

  1. Filling in the "Addresses" dialog:
    In this dialog, the multicast range is chosen whereby the IP addresses through are reserved for multicast circuits. This address range is recognized by every block as a multicast frame and is not used for communication via standard communication connections.
    The local and remote ports can be assigned unlimitedly, as small port numbers are reserved for special tasks (well known ports). When the first multicast circuit is created, as a default the circuit is offered.

Fig. 2: Properties of the UDP connection

  1. What a connection created in NETPRO should look like:
    In NETPRO, a connection is displayed with the common procedure. It can be distinguished from a common transport connection by the field "Partner". If it is a multicast connection, "All Multicast Nodes" is entered.

  IE-CPs_Multicast_03_e.gif ( 17 KB )  

Recommendations for project development:

To ensure smooth communication, the following develompent instructions must be observed:

  • Local and remote port of a multicast connection must be identical.
    The multicast circuits that are configured are registered in the LAN controller. This way, the incoming telegrams are not ignored, but processed by the CP.
    As soon as the telegrams have passed the LAN controller, the only relevant information left is the number of the port in use!

    Between two stations, exactly one multicast connection is configured.

      Station: 1 Station: 2
    IP address
    MC circuit
    local port 2000 8000
    remote port 8000 8000

    Case 1: Station 1 sends data from the multicast circuit
    This works, as the remote port 8000 of station 1 corresponds to the local port 8000 of Station 2

    Case 2: Station 2 sends data to the multicast circuit
    The telegram cannot be received by Station 1, although it is a node in the multicast circuit, because the local port 2000 of Station 2 is not identical to the remote port 8000 of Station 1.

    To manage both cases, remote and local ports must always be identical.


  • Special issue about the choice of multicast addresses
    In this example, a multicast telegram is to be sent from Station 1 to Station 2 as well.

      Station: 1 Station: 2 Station: 3
    MC circuit
    local port 8000 8000 8000
    remote port 8000 8000 8000

    As all port numbers are identical in this case, a bidirectional data transfer between these two stations is possible without restrictions.
    But, interesting enough, this telegram is also received by Station 3. At first sight, this is not supposed to work, as Station 3 is no node in circuit
    To understand this, you have to look at the mechanism of building the multicast MAC addresses:

    Display of the multicast addresses on the LAN:

    For multicast, the last 3 bytes of the IP address are copied to the last 3 bytes of the MAC address 01.00.5E.00.00.00. This is the MAC address which is registered for the various circuits in the LAN controllers. This way you ensure that the telegrams can pass the respective LAN controller. Additionally, the highest bit of the first copied byte of the address is ignored and is always 0.
    The MAC address that has been created is also visible as destination address in the telegrams in the LAN.

    The following three multicast circuits all lead to the same entry in the LAN controller, resp. to the same MAC address:
    MAC address = 01.00.5E.00.01.00

    This shows that different multicast IP addresses actually represent the same multicast circuit. You should observe this when assigning multicast circuits to avoid unwanted messages on unaddressed stations.
    This is an instruction that follows valid RFC (internet standard).

Blocks that support multicast connections:


First delivery


Type of block

Firmware version

1 Dec. 2002 6GK7 343-1EX10-0XE0 CP 343-1 starting from Version V2.1


Apr. 2002

6GK7 343-1EX11-0XE0

CP 343-1

starting from Version V2.0.x


Dec. 2002

6GK7 343-1EX20-0XE0

CP 343-1

starting from Version V1.0


Aug. 2001

6GK7 443-1EX10-0XE0

CP 443-1

starting from Version V2.0.31


Aug. 2001

6GK7 443-1EX11-0XE0

CP 443-1

starting from Version V2.0.31


May 2004

6GK7 443-1EX40-0XE0

CP 443-1 Advanced

starting from Version V1.0


Dec. 2001

6GK7 343-1GX00-0XE0

CP 343-1 IT

starting from Version V2.0.x


March 2002

6GK7 343-1GX11-0XE0

CP 343-1 IT

starting from Version V2.0.x


Feb. 2004

6GK7 343-1GX20-0XE0

CP 343-1 IT

starting from Version V1.0


Dec. 2001

6GK7 443-1GX10-0XE0

CP 443-1 IT

starting from Version V2.0.x


Dec. 2001

6GK7 443-1GX11-0XE0

CP 443-1 IT

starting from Version V2.0.x


Nov. 2001

6GK7 343-1HX00-0XE0

CP 343-1 PN

starting from Version V1.0.x

Table 1: Blocks overview

network protocol, Gateway, TCP/IP, Frame