Preamble
Before you start reading, please let me point out:
- The following content is not “the complete knowledge about networks and services” (not even almost
), and it’s not intended to be. - They’re dozens of thousands of websites out there, explaining that stuff much more in detail.
- I’m aware that almost everybody who’s reading this post already knows what’s a IP address, a subnet mask and so on, and has already used those things many, many times.
- They’re already some posts and very good explanations in our Community about those network topics
But why I’m posting it nevertheless?
Because I think it makes sense to summarize in a single place some simple explanatory words about terms related to “network technology on the PLC”, that I have been asked about frequently over the years.
And I would be very happy if others will add their information by answering to this post, so that it can grow to a reference on network topics that’s helpful in our daily business !
ISO / OSI Reference Model
The OSI model is a reference architecture for network communication protocols.
It consists of 7 layers, and every layer has a dedicated task inside a complete communication. This model is almost everywhere used when talking about:
- How a communication works, and what components are involved.
- What devices and which protocols are used for what dedicated tasks
- How the different tasks of a communication system have to be segregated.
- How communication systems (hardware and driver) have to be designed.
Every communication content flows through all layers, logically only the same layers are interacting between devices.
What does that mean? Layers does not have information from other layers to get the whole communication job done!
- Layer 7: Application Layer → The “end user layer”, here the content is processed (your code!).
- Layer 6: Presentation Layer → Formatting data, for example if encryption is used.
- Layer 5: Session Layer → Synchronization of different sessions, socket handling.
- Layer 4: Transport Layer → End-to-end connections, for example TCP, UDP.
- Layer 3: Network Layer → Logical addressing (“Packets”), for example IP. Hardware: Routers.
- Layer 2: Data Link Layer → Physical addressing (“Frames”), for Example Ethernet. Hardware: Switches.
- Layer 1: Physical Layer → Physical medium, for example cable RJ45, wireless. Hardware: Hubs.
ARP
The Address Resolution Protocol is used for physical addressing a communication partner, it works on layer 2.
If a device (sender) wants to communicate to a another one (receiver) for example using IP, also the information about the physical address of the receiver is needed. So, sending an IP packet to the receiver (on layer 3) leads first to a so-called ARP Request (on layer 2) from the sender to determine the physical address of the communication partner, followed by an ARP response from the receiver. After that, when both communication partners know each other’s physical address, they can communicate.
To avoid a network overload by too many ARP messages, every operating system stores the determined physical addresses temporary in the so-called ARP cache “as long as a communication is active plus some more minutes (if another communication will start)”. After that time, the temporary information is deleted out of the cache.
MAC Address
The Media Access Control address is the physical address of a network interface. It has a size of 6 Byte, most often written as hexadecimal numbers, every byte divided by a ‘ : ’, a ‘ - ‘, or something similar.
The leading 3 bytes are used as a “interface / chipset manufacturer code” (for example 00:60:65 stands for B&R), the following 3 bytes are a unique number.
Example: 00:60:65:13:42:12
IP
The Internet Protocol is used for logical addressing and forwarding data packets from the sender to the receiver. IP works on layer 3 of the OSI model.
They’re two versions existing: IP Version 4 and 6. On the PLC, only IPv4 is available by now.
IP Address
The 4-byte address of the IP interface, most often written as “dotted-string” value.
An IP address is the unique address of an IP device inside the whole IP network the address belongs to.
Examples:
192.168.1.100
10.100.50.10
Subnet mask
The 4-byte mask holding the information “to which subnet belongs the IP address” (normally written as “dotted-string” value). It’s interpreted bitwise, always with only two blocks of 1 and 0, the “1-block” comes first followed by the “0-block”.
The “1-block” defines the “Network Part” of an IP address (to what network an address belongs to), the “0-block” defines the “Host Part” of the address (the unique host number inside that network).
Examples:
255.255.255.0 (= 11111111 11111111 11111111 00000000)
255.224.0.0 (= 11111111 11100000 00000000 00000000)
IP Network
Every IP address where network part (defined by the subnet mask) is equal, belongs to the same IP network.
Without Routing, IP devices can only communicate to devices that are in the same IP network.
As already mentioned, the IP Network definition is a “logical definition”. So, is mostly independent of “where a device is located / plugged in”. For example, if two devices are plugged into the same switch (layer 2 connection) but aren’t configured to be in the same IP network (layer 3 addressing), they can’t communicate to each other without a router / routing.
IP Network Address
The lowest IP address of a network is the Network address, so more or less “the name of the network itself”. It can be calculated by a bitwise AND of IP address and Subnet mask.
Examples:
IP 192.168.1.100, SN 255.255.255.0: Network address → IP AND SN = 192.168.1.0
IP 10.100.50.1, SN 255.224.0.0: Network address → IP AND SN = 10.96.0.0
Often, the IP network is described in a shortened way “IP Network Address / Number of high bits in the Subnet mask”.
Examples:
Network 192.168.1.0, SN 255.255.255.0 = 192.168.1.0/24
Network 10.96.0.0, SN 255.224.0.0 = 10.96.0.0/11
IP Network Broadcast Address
The highest IP address in a Network is the network’s Broadcast Address.
It can be calculated by a bitwise AND of the Network Address and the INVERTED Subnet Mask: “Network Address (NA) AND NOT Subnet Mask (SN)”.
Examples:
NA 192.168.1.0 SN 255.255.255.0: Network Broadcast address → NA AND NOT SN = 192.168.1.255
NA 10.96.0.0 SN 255.224.0.0: Network Broadcast address = NA AND NOT SN = 10.127.255.255
Every member of a network must process a packet that is sent to the networks broadcast address, so this address is used for special purposes, for example “send a info packet to the whole network”.
But be aware: as described, every member must read and process such packets, so Broadcasts bring a much higher amount of load to the whole network and all the devices – so only use it if you really, really need it!
Private IP Addresses / Networks
IP Networks and their IP Addresses are classified as “Public” and “Private”. Public IP addresses are used in the “public area” → mostly “the Internet”. Private networks are defined for “Intranet Networks”, for example the Network at home, the machine’s network, the company’s internal network.
The Private IP Address ranges / Networks are defined as:
10.0.0.0 to 10.255.255.255
Class A Networks – mostly used with a Subnet Mask of 255.0.0.0 (/8) or higher.
172.16.0.0 to 172.31.255.255
Class B Networks – mostly used with a Subnet Mask of 255.255.0.0 (/16) or higher.
192.168.0.0 to 192.168.255.255
Class C Networks – mostly used with a Subnet Mask of 255.255.255.0 (/24) or higher.
There are also networks of Class D (224.0.0.0 to 239.255.255.255) and Class E (240.0.0.0 to 255.255.255.255), those networks normally aren’t directly allocated to hosts but are reserved for special purposes like Multicasting groups / addresses and so on.
Every other IP address not in that ranges above are Public IP addresses.
Be aware: Never use Public IP Addresses / Networks directly in devices like PLC’s, Visualization Devices, Development notebooks and so on (except you’re a network administrator and you know exactly what you’re doing ).
IP Default Gateway
The IP address of the device, that is used if a packet is send to a receiver who is not in the same network, and no routes are already known how to reach this network. The Default Gateway “has to know how to reach all of those other networks” (very often, the Default Gateway is a router).
Why do I need a Default Gateway (sometimes)?
If an IP stack has to send a packet to a different network than the own one and where no route is configured already, the packet is sent to the default gateway assuming that the Default Gateway knows the route to the receiver of the packet. For example, this unknown network could be “the Internet”.
For this to work, the Default Gateway not only has to have the route to the remote network, it must also be accessible from the local network of the device that wants to use the Default Gateway (for example, the PLC’s local network) – that means, like described above, the Default Gateway’s IP Address is always in the same IP Network then the devices using it.
When your device is a DHCP client, often the DHCP server delivers not only an IP Address and a Subnet mask, but also the Default Gateway address.
IP Routing / Static Routes
If devices out of different IP networks should communicate, an IP Route is needed.
A Route describes “how to find the way to a remote network”.
Normally, hardware-based Routers do this job (see Default Gateway) in bigger infrastructures like Intranets or the Internet.
Most often, the routes are managed by special “routing information exchange protocols” inside the routers, because such networks are too big and too complex to maintain the routes manually; that’s one of the reasons why the such routes are called “dynamic routes”. For example, a connection to an Internet website goes through several routers until the destination is reached (your device → your local Internet router → your Providers router to the backbone → …. → the router of the destinations device → the destination device … and of course, all the way back).
In such networks, every router only knows his direct neighbors, and the communication packets are transferred from one to the next (the so called “hop”, because a packet “hops” over different devices).
But sometimes there is also the need for a so called “static route”, a route that is set up manually in the devices, for example to connect only two networks without a full-featured hardware-based router.
To understand why a connection does not work or how to setup a static route, it’s good to know how routing works in principle.
Routes are managed in so called Routing Tables. The entries in this tables include the definition of the remote network (= the Network Address and the Subnet mask), and the interface to use to send the data (= the IP address of the interface or the device, that resides in the own network or own device and that “knows how to proceed with the data”).
Let’s make an example:
You have a development notebook that communicates with a PLC. This PLC has 2 network interfaces, one is connected to the network of your notebook, the other is connected to the machines internal network, which is a different one. You want to communicate with your notebook to a device in the machine network that also has an IP interface – this could be done with static routing.
But please note that EVERY DEVICE involved in that communication has to know about the route(s)!
Let’s say, your notebooks network configuration is 192.168.10.123/24, the device in the machine has the configuration 192.168.200.10/24, and the PLC has the two configurations 192.168.10.10/24 (first network) and 192.168.200.200/24 (second network).
Every device needs the information in its routing table “who is the remote network and how to reach it”, that means: the remote network address, the remote network subnet mask, and the interface IP address.
Remote Network Address — Remote Network Subnet Mask — Interface IP Address
Static route inside the notebook (in first network, 192.168.10.123)
192.168.200.0 — 255.255.255.0 — 192.168.10.10
Because the routing PLC has already IP interfaces in both routed networks, this PLC itself doesn’t need a static route, like explained perfectly by Austin in this thread.
Static route inside the machines network device (in second network, 192.168.200.10)
192.168.10.0 — 255.255.255.0 — 192.168.200.200
DHCP
The Dynamic Host Configuration Protocol is used to setup devices in an IP network automatically.
When a device is configured as DHCP client, it sends a broadcast packet into its network asking for an IP configuration from a server.
If a DHCP server exists in the network, it provides a IP address and Subnet mask from it’s pool of addresses, and also very often some additional network information like the Default Gateway of the network, the DNS server, and so on.
The DHCP client must renew its configuration request from time to time (depending on the DHCP server configuration). So even if most DHCP servers try to assign the same IP address as before, it’s not guaranteed that the IP address stays the same!
DNS
The Domain Name Service is used to translate an IP address to a Hostname and vice versa.
Every IP conversation uses IP addresses to let devices communicate. But remembering the right IP addresses, or even knowing them (for example when using DHCP), is hard to realize.
Therefore, in most cases devices also have a hostname, and DNS servers are managing lists of “which name belongs to what IP address” and do deliver information about name and address.
Because the DNS servers are the only ones knowing “who is who”, setting up the use of a DNS server is always done by its IP address only (because “who should be asked to translate the name of the name server”? ).
One example of many public DNS servers is Google’s 8.8.8.8
FQDN
FQDN stands for Full Qualified Domain Name and means more or less “the complete / absolute name” of a system (device or service).
If systems are grouped in domains, the FQDN shows the complete system path inside the Domain structure (the DNS directory). Devices can have a FQDNs, but also services like websites.
IF communicating with systems of a domain, you should always use the FQDN, or, if you integrate a system into a domain, you should also configure the DNS suffix (the “general part” of the FQDN).
NTP
The Network Time Protocol can be used to retrieve a actual date and time information from a NTP server. If a device acts as NTP client, normally not only the information itself is retrieved but also the devices’ internal clock is set.
NTP server are publicly accessible via Internet. I suggest to use a NTP cluster address, for Germany for example de.pool.ntp.org. Because such clusters are functional even if a single server is not responsive (and don’t forget to activate the DNS client service so that the system can resolve the FQDN of the NTP server).
NTP servers do not spread proactive there information to clients, the client has to contact periodically the server to retrieve the data. Therefore it’s good to know, how the client do this:
NTP is designed for a permanent, but “slow” data reconciliation.
The interval of this data gathering is decided by the NTP client implementation / operating system, and often is changing / is getting slower as longer as the clients runs: “the client decides by his own, how good he’s syncronized and when he will start the next update”.
That means: if you’re using a own NTP server in your network, and the NTP servers time is changing / “jumping”, such a time jump will not immediately taken over by all clients!
It can last “some minutes or even more”, depending on the client’s sync state and runtime, until the clients’ clock is set to the servers’ changed date and time.
TCP
The Transmission Control Protocol is the most common stream-based transport protocol working on layer 4.
TCP protocol guarantees by “building a protocol-controlled point-to-point data channel:
- that the order of packets sent keep valid until received, even if the packets itself have different routes on their way to the destination.
- that packets lost on their way are automatically retransmitted by the TCP stack (in the right order).
- that sender and receiver are synchronized about the processing of the data (if receiver can’t receive more data, sender waits until receiver is ready to go on).
That means, the data stream arriving is always consistent. TCP fits perfectly, if data consistency has the highest priority, especially over different routes and devices.
TCP has also some “disadvantages” like overhead inside the protocol and the drivers (controlling the transmission, buffering data at the sender until acknowledged by the receiver, keeping the point-to-point channel consistent) and a very unpredictable time behavior in case of re-transmissions, different data processing speed of sender and receiver, and so on.
TCP is often explained with a “phone call”:
it’s point-to-point, calling and called person (=sender and receiver) know if the call is established or has ended, the duration of the call (= amount of data inside the whole stream) is not known when starting the call, and the data arrives always in the right order.
But, exactly like with TCP, some problems can occur: you have to repeat your data, sometimes very often (for example if the receiver has bad cell phone reception), in some cases you even do not recognize immediately that the call was interrupted and you wait for new data, and if you try calling back the line is still busy because the receiver hasn’t hanged up yet.
UDP
The User Datagram Protocol is a packet-oriented transmission protocol working on layer 4.
It does not have any protocol-integrated transmission control mechanisms, it’s more like “fire-and-forget”: you send a packet, but you don’t know if it was received until the receiver send back some data.
UDP fits perfectly, if the amount of data that has to be consistent is less then one packet (when using Standard Ethernet, it’s about 1432-1472 byte, depending on some IP options), if sending of packets should be “as lean as possible” and no additional data-flow mechanisms are needed (for example, if you want send cyclic a physical value, very often only the most recent value is interesting, no matter if there were some values in the past received or not), or if “point-to-multipoint” communication is needed (multicasting, broadcasting).
UDP is often explained with a “postal letter”:
you write the letter and you put it into the mailbox, that’s it. If your letter was received you will only know, if the receiver write’s back to you. Being at the mailbox, you can put more than one letter into (to many different receivers if wanted), or even put in direct mail (= broadcast / multicast).
(Well Known) Ports
Ports are “the address of an application”, and have a value between 1-65535. In every TCP or UDP communication, the assignment of incoming or outgoing data to the code / program that processes this data is done via a port. Doing so, different applications on a system can use the same IP interface and transport protocol for data transmission without “mixing up the packets”.
The ports 1-1023 are the so-called Well Known Ports. That means that this ports are reserved for dedicated protocols (by IANA, the Internet Assigned Numbers Authority), for example TCP port 80 = HTTP protocol, UDP port 123 = NTP protocol.
Also in the range above 1023, many ports are used always for the same protocol, for example TCP port 11169 = ANSL (the PLC online protocol).
So if you’re implementing a own/proprietary communciation between devices, to avoid problems or missunderstandings in the whole network, please
- never use well known ports for your own protocols.
- please choose ports above 1023, that are not linked to existing protocols.
They’re lists in the internet, where you can find out the ranges of unused ports.
By the way, using UDP or TCP, the same port can be used for sending and receiving data if wanted, independent of who’s client and who’s server, so TCP/UDP ports are bi-directional.
