on 12-13-2023 07:14 AM
Profinet Real-Time (Profinet RT) is an Industrial Ethernet protocol developed by the Profibus & Profinet International (PI) organization. It enables real-time communication for industrial automation applications, offering deterministic behavior, high-speed transmission, and robustness. Profinet RT ensures precise synchronization and consistent timing, making it ideal for applications such as motion control, process automation, and distributed I/O systems.
Cisco VLAN-based switches provide a flexible and scalable solution for network segmentation, allowing organizations to segregate traffic and optimize network performance. VLANs (Virtual Local Area Networks) enable logical separation of network devices into different broadcast domains, improving security, and reducing network congestion. Cisco switches support various VLAN configurations, including voice VLANs, which prioritize voice traffic for VoIP applications.
Profinet RT packets consist of a header and payload. The header contains information such as source and destination MAC addresses, IP addresses, and Profinet-specific fields like the Real-Time Communication (RTC) header. The payload carries the actual data being transmitted between Profinet devices, such as control messages, I/O data, and diagnostic information.
An example of Profinet RT packet is shown below
Priority is assigned to PROFINET real-time messages in accordance with standard IEEE 802.1Q.
The VLAN ID 0 with VLAN priority 6 is used for Profinet Real Time packets. The general procedure for assigning priority is described in the standard IEEE 802.1P.
The CoS/802.1p to Queue table determines the egress queues of the incoming packets based on the 802.1p priority in their VLAN tags. For incoming untagged packets, the 802.1p priority will be the default CoS/802.1p priority assigned to the ingress ports.
By changing the CoS/802.1p to Queue mapping, the queue schedule method, and bandwidth allocation, it is possible to achieve the desired QoS in a network.
Quality of Service configuration may vary from platform to platform and before configuring any specific QoS feature, one must check the specific configuration guide for the platform and IOS version.
For example, in C9300 platform, IPP can be used for marking traffic based on specific protocol.
The 9300 protocol ID IPP match QoS is a feature available on Cisco Catalyst 9300 Series switches that allows for more granular control over Quality of Service (QoS) policies.
This feature works by matching the Differentiated Services Code Point (DSCP) value in the IP header of incoming packets with the configured QoS policy. The DSCP value is a field in the IP header that indicates the priority level of the packet.
When the switch receives a packet, it examines the DSCP value and compares it to the QoS policy configured for the specific protocol ID. If there is a match, the switch applies the corresponding QoS policy to the packet. If there is no match, the default QoS policy is applied.
This feature can be useful in environments where multiple applications with different QoS requirements are running simultaneously. By using the 9300 protocol ID IPP match QoS feature, network administrators can ensure that each application receives the appropriate level of service based on its priority level.
By classifying traffic based on its type, the 9300 protocol ID IPP match QoS can help prevent network congestion and ensure that resources are allocated appropriately for Profinet Real Time traffic.
To configure QoS on a Cisco switch for ProfiNet traffic, you can follow these general steps:
Here's an example configuration[1]:
class-map match-any PROFINET
match protocol profinet
policy-map QOS-PROFINET
class PROFINET
set dscp cs5
priority percent 50 interface
GigabitEthernet0/1
service-policy input QOS-PROFINET
In this example, the class map matches any ProfiNet traffic using the "profinet" protocol. The policy map sets the DSCP value of the traffic to "cs5" and assigns it to a priority queue with 50% of the available bandwidth. Finally, the policy map is applied to the input interface GigabitEthernet0/1.
Note that specific configuration details may vary depending on your specific Cisco switch model and network requirements.
Incompatibility with Industrial Ethernet Infrastructure: Industrial networks are often built with a combination of Profinet-enabled devices and Cisco VLAN-based switches. Incompatibility between Profinet RT packets and these switches can create interoperability challenges, hindering the integration of Profinet devices into the existing network infrastructure.
While Cisco VLAN-based switches offer numerous benefits for network segmentation and optimization, they have certain limitations when it comes to supporting Profinet RT packets.
Cisco has a portfolio of Industrial switches supporting Profinet natively, not only from the forwarding perspective but also as Profinet devices and GSD configuration capabilities. The following link shows how to configure Profinet natively on a Cisco IE4000 Industrial switch:
The rest of the Cisco VLAN-based switches may have issues forwarding specific Profinet RT packets because of the standard Profinet packet using VLAN 0.
Profinet devices use Vlan 0 for discovery and some other aspects of the protocol. The vlan 0 tagged packets are not forwarded when the profinet device is directly connected to a Catalyst switch interface in access mode.
In order for the PROFINET real-time communication to be possible also in a Virtual Local Area Network (VLAN) and thus also over switches that can evaluate the VLAN tag, the switches must support the following:
PROFINET real-time messages with Ethernet type 0x8892 must be accepted and forwarded.
PROFINET real-time messages with VLAN ID 0 must be accepted by the switch and tagged with the prioritization by the configuration in the switch in a separate VLAN x.
The VLAN ID 0 of the PROFINET real-time message must be set by the switch where the Profinet device is connected to any VLAN ID (tagged VLAN), for example VLAN ID 100. This permits to copy the PCP bits of the 802.1p and take into account the priority for Profinet RT packets.
The last switch that forwards the PROFINET real-time message to a terminal node or other IO device can remove the VLAN tag from the PROFINET real-time message before forwarding on the target port (untagged VLAN).
To overcome these limitations and ensure seamless communication between Profinet devices on a Cisco VLAN-based switch network, a workaround involving the configuration of access ports with a voice VLAN can be employed. This workaround prioritizes Profinet RT traffic and ensures its efficient transmission and forwarding within the network, mitigating the issues caused by default switch configurations.
Option 1. Configure the port as a trunk
Option 2.
Note: Considering that the access port is going to have a single device and to avoid other vlans crossing the port, for security reasons, this is the recommended option for Profinet end-devices connected to the access port.
Configure the Access port with voice vlan dot1p as shown below:
dot1p—Configures the switch to accept voice and data IEEE 802.1p priority frames tagged with VLAN ID 0 (the native VLAN). By default, the switch drops all voice and data traffic tagged with VLAN 0. If configured for 802.1p the Cisco IP Phone forwards the traffic with an IEEE 802.1p priority of 5.
Please refer to the following documentation:
With the option switchport voice vlan dotlp.
On ingress at switchport, the IEEE standard mentions that a switch must never transmit priority tagged frames (those with VID 0). Hence it must associate such frames with an actual VID or send it untagged. Depending on how the port is configured (trunk mode, dot1p), such frames will fall into the native vlan.
So finally switch will receive all frames from the Profinet device with null VID set. From that point, as per the standard it must associate it with valid VID for transmission or send it untagged.
For null VID, for priority tagged frames, since they must use dotlq header, just to set user priority bits, it sets VID in the frame to 0. When such frames enter the switchport, as per standards the switch must (Section 8.4.4 of the IEEE Std 802.1Q-1998 paper) tag it with a non null VID or send it untagged. Native vlan should be non-null VID, which the switch associates with such frames.
The Cisco VLAN based switch with any of these two workarounds, encodes the Profinet RT frame by adding an 802.1q header with non-null VID and prioritizes the traffic as high priority by setting the priority bits of the PCP field ( Priority Code Point) in the 802.1q header. These packets are then forwarded with the highest priority crossing the switching infrastructure.
Note: It has been observed in customer production environment that changing the access port characteristics to support Profinet RT adding the aforementioned commands, the port still does not forward these packets and rejects any other packets. Shutting down and shutting up the port fixes this temporary issue re-establishing Profinet and other IP traffic on the same port.
VLAN Configuration Guide, Cisco IOS Release 15.2(7)Ex (Catalyst 1000 Switches) https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst1000/software/releases/15_2_7_e/configuration_guides/vlan/b_1527e_vlan_c1000_cg/configuring_voice_vlan.html
IEEE 802.1Q-1998
IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks https://standards.ieee.org/ieee/802.1Q/1039/
Profinet RT : Real-Time Performance
https://us.profinet.com/profinet-rt-real-time-performance/
Profinet Technology
https://www.profibus.com/technology/profinet
[1] Please check specific configuration guidelines for your specific platform
Hi @fereyes ,
Firts of all, thank you for this topic, is very usefull for my enviroment with multiple PLC's running in a C9200 network.
I have working Profinet with the workaround 2 in some of my C9200, but seems to be working only localy (on the same switch), when the Profinet packet try to reach another switch, the traffic is not working.
I was reviewing the post and the references, and i have a question that i think has not been cleary comment in this topic, in order to make it works (Profinet trough different switches), should i have enabled the global command "mls qos" in all of my switches?
Thank you in advance.
PD: Sorry for any lenguage mistake, i'm not native english speaker.
BR.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: