PROFINET VLAN comm question

My experience with VLANs in the past has been that everything on the VLAN inside of the corresponding subnet should be able to speak to one another without going through a gateway.

I have 2 devices plugged directly beside each other, but they can only speak to one another after the default gateway is set.

I am afraid this is interfering with the Profinet communication. I cannot speak to a device on the same VLAN and I am thinking it is because Profinet is not intended for Layer 2 communication.

Do i need to have IT guys look into the reason why a default gateway is required for individual VLAN comms?

ahuberee said:

I am afraid this is interfering with the Profinet communication. I cannot speak to a device on the same VLAN and I am thinking it is because Profinet is not intended for Layer 2 communication.

Click to expand...

Profinet IO is not intended as a Layer 3 application. It runs at layer 2 (MAC addresses, not IP addresses). In theory, this saves overhead of a few different kinds.

In general, everything on the same VLAN should be able to talk to each other, as long as all the switches are configured correctly.

What IP addresses and subnets are the two devices?

What are the VLAN settings on the switch?

Ah yes, I meant "Profinet is not intended for Layer 3"* Thank you for confirming this.

I've run through a few tests. Connecting the device and PLC to an unmanaged switch works!
Connecting to the managed switch with VLAN setup does not. I am actually able to ping devices on the subnet now after removing the gateway settings (the IT guys must have fixed this problem recently).

It seems like the Data Link Layer (L2) stuff is getting blocked.

Here is the configuration I am trying to get to work.

IO Device is located on swtich #1. It is plugged into a VLAN 3 configured port.
IP: 10.1.33.120
Subnet Mask: 255.255.255.0

PLC is located on a separate switch #2. It is plugged into a VLAN 3 configured port.
IP: 10.1.33.10
Subnet Mask: 255.255.255.0

Computer is located on the same switch as the PLC (Switch #2). It is plugged into VLAN 3 configured port.
IP: 10.1.33.100
Subnet Mask: 255.255.255.0

No default gateway is specified. I can ping the device, I can ping the PLC. The PLC does not see the device.

I'm not sure if this will help, but in the past I have had simliar issues with Cisco switches.

They were dropping the packets (due to being 'runt's undersized). Which I don't understand since the Profinet standard is supposed to include padding to the minimum packet size.

To get around this we had to enable VOIP on the channels.

Heading out the door right now. Can try to dig up more details later if needed.

It sounds like the switch is doing something to block the PN traffic. You or the IT guy might be able to check the switch's logs to see if it listed a reason for the dropped packets.

Can you do device discovery from your laptop? That would be Proneta, Accessible nodes, something like that.

JOLTRON said:

They were dropping the packets (due to being 'runt's undersized). Which I don't understand since the Profinet standard is supposed to include padding to the minimum packet size.

Click to expand...

That's wacky! You're right, Profinet is supposed to pad things out, but I hear rumors of lots of weird issues when using enterprise instead of industrial HW. VLAN 0 for the priority is another common problem.

I had heard of Profinet "runt" packets getting dropped. I placed this information into my IT guy's hands months ago. My guess is he never did anything with it.

https://support.industry.siemens.co...nd-simatic-profinet/106045?page=1&pageSize=10
A get around this you must enable "switchport voice vlan dot1p" which inserts a 32 bit field with a VLAN-ID and priority information to increase the the ethernet frame beyond 64 Bytes allowing the device to forward the frames as expected.

Click to expand...

Can you do device discovery from your laptop?

Click to expand...

TIA Portal finds it just fine. I can ping it set IP and Profinet Name

This is interesting. I knew that PROFINET only operated at layer 2 which was a consideration to be aware of but it seems some other intricacies are needed to get it to play nice with VLAN's and certain managed switches.

It looks like PROFINET packets from the controller are tagged with VLAN ID 0 as default which is used to mark it as a prioritized packet.

Siemens - Which settings do you have to comply with in a PROFINET RT network in conjunction with VLAN switches?

With this in mind it seems that the managed switch must also have VLAN 0 Priority Tagging Support.

For Cisco switches this seems to be limited to the industrial IE series and also AB Stratix I imagine.

Cisco VLAN 0 Priority Tagging Support

The command for Cisco switches is to enable 'encapsulation priority-tagged' for each specific interface.

It seems there may also be a workaround for Cisco switches that do not support VLAN 0 priority tagging.

Refer to this thread on the Cisco forums where someone changed the switchport from access to trunk mode to get things working. Perhaps this works because by default the trunk port allows all VLAN's unless explicitly specified.

Wish I could do some testing myself, I have an AB Stratix 5700 and S7-1200 PLC sitting here in my office, but no other PROFINET remote IO to test it with.

Interested to hear the result of this.


Edit:
After some more research it seems the 'encapsulation priority-tagged' may be deprecated or is only specifically for the Cisco IE series. It definitely doesn't seem to work work on AB Stratix 5700 / Cisco Catalyst.
The correct command is 'switchport voice vlan XX' or 'switchport voice vlan 3' in your situation. This enables support for VLAN 0 priority tagging on the switchport which is required for PROFINET.

mk42 said:

That's wacky! You're right, Profinet is supposed to pad things out, but I hear rumors of lots of weird issues when using enterprise instead of industrial HW. VLAN 0 for the priority is another common problem.

Click to expand...

I was thinking about it, and the "runt" packets may be related to the lack of Vlan 0 support. If the switch strips out the priority tag from the unknown VLAN (0), that would drop off 4 bytes, shrinking from 64 to 60.

mk42 said:

I was thinking about it, and the "runt" packets may be related to the lack of Vlan 0 support. If the switch strips out the priority tag from the unknown VLAN (0), that would drop off 4 bytes, shrinking from 64 to 60.

Click to expand...

That makes sense. Then when you add voice / VOIP it would add a new VLAN tag that would then increase the size to be within the tolerance.

JOLTRON said:

That makes sense. Then when you add voice / VOIP it would add a new VLAN tag that would then increase the size to be within the tolerance.

Click to expand...

I think the trick, though, is that you've then lost your Priority 6 on your IO traffic. You could just declare ALL PLC/IO traffic as high priority if you want, but plenty of it isn't real-time traffic that needs to be prioritized.

To follow up, the IT guys did configure the ports as mentioned above:

switchport voice vlan dot1p

Click to expand...

This did fix the problem.