Get best of the week

What does a network with PRP redundancy look like in WireShark

Kat

You can find in our blog detailed information about the algorithm of the PRP protocol. Now we offer to “dissect” traffic from the network with PRP. Take a look at the RCT trailer, Supervision Frame, and how redundancy management is organized through all of this. Anyone interested under cat.

PRP General principles

All general principles have been outlined in this article . The current post is its continuation. We recommend that you first read the first article. The following questions are examined in its composition:

  • PRP network structure
  • PRP network elements and their purpose
  • DAN structure
  • Interoperability between SAN and DAN
  • DAN Modes
  • Duplicate accept
  • Duplicate discard
  • Channel level implementation
  • Work algorithm

In short, PRP-based redundancy is done by duplicating frames. Each frame is duplicated by the sender, and the frames are transmitted through two networks isolated from each other. The receiving node processes the frame that arrived first and discards the second. If a frame arrives “broken” or one of the networks has been lost, then there is always a second frame. Due to this, "seamless" redundancy is achieved - i.e. redundancy with a convergence time of almost 0 ms.

The general structure of the network is as follows:



For details about what these abbreviations are, details of the protocol algorithm and so on - you are welcome to the article mentioned above. In this post, we will pay more attention to the frame and the RCT trailer.

RCT stands for Redundancy Control Trailer, a backup control trailer.

This trailer is added to the frame. It is used to manage redundancy.



RCT includes:

  • 16-bit sequence number;
  • 4-bit network identifier, 1010 (0xA) for LAN A and 1011 (0xB) for LAN B;
  • 12-bit frame size.

Accordingly, what is management?

  1. Detection of incorrect connection of interfaces. DAN determines that a frame with LAN ID B arrives on LAN A and vice versa. In this case, the DAN increases the error counter of the mixed frames (IreCntErrWrongLan). The device will accept packets, but considers it an error and will consider the number of invalid packets.
  2. Duplicate Discard. , , , PRP . (Duplicate Discard) .
  3. PRP-. NodeTable, DAN SAN .

Let's catch traffic on the network with PRP and see how PRP works.

Getting to practice

To “dissect” a frame with PRP, you first need to perform two tasks: generate frames and catch frames.

Generate

Let's start with the Generate task.

Let's put together a simple network where you can find some PRP packets.



Pursuing the goal of catching all the frames on the network with PRP, we take a couple of laptops, two RedBox's and two managed switches.

As RedBoxes we took FL RED 2003E PRP - 2701863 .

As switches, we took two FL SWITCH 2206-2FX - 2702330. The switches are not power and PRP support is not stated in them. At the same time, we will check how the switches deal with frames containing RCT.

We built the simplest network, generated PRP frames. Now let's move on to the second task - to “catch”.

“Catch”

To catch traffic with an RCT trailer, we will connect a laptop with Wireshark on board to one of the managed switches. On the switch, configure Port Mirroring to mirror traffic from the network to the laptop for analysis.



Run ping from one host (192.168.0.200) to the second (192.168.0.60) and catch ICMP packets in Wireshark.



What is in the frame?

Take the ICMP packet from 192.168.0.200 to 192.168.0.60.



From the screenshot in Wireshark it can be seen that RCT contains two more fields than was described at the beginning. There is also a protocol version and PRP suffix. Earlier, I omitted this data, because they do not carry a payload.

Accordingly, in the frame we see:

  • PRP version information.
  • Sequence number - the PRP node maintains for each DAN its counter of sent and sent packets. This is required to uniquely identify duplicate packets and run the PRP algorithm.
  • The LAN ID determines whether the frame belongs to LAN A or LAN B. It depends on the interface from which it was sent.
  • The size is determined by the size of the LSDU and RCT fields. Does not take into account the whole frame size, as the size of other fields may change during transmission. For example, when adding a VLAN ID to a frame during transmission, its size will change.
  • PRP suffix. This suffix is ​​the same for all frames with a PRP trailer and has a value of 0x88fb. Network independent (LAN A or LAN B).

What does the protocol version mean?

PRP can be of two versions:

  • PRP-0 (PRP 2010, IEC 62439-3 (2010));
  • PRP-1 (PRP 2012, IEC 62439-3 (2012)).

The most important point - PRP-0 and PRP-1 are incompatible.

PRP-1 introduced several fundamentally important changes:
  • extended RCT;
  • the principle of the Duplicate Discard algorithm has been changed;
  • compatibility between DANH (HSR) and DANP (PRP) was introduced.

The RCT in PRP-1 has become closer to HSR.

PRP-0 is rare in real world applications.

What else is in the PRP network?

Each PRP node also sends a Supervision Frame.

Supervision Frame is used to monitor the status of each node in the network. Any default DAN sends a Supervision Frame every 2 seconds. The sending interval can be changed.

Supervision Frame has the following options:

  • sent to Multicast group 01-15-4E-00-01-XX;
  • has Ethertype 0x88FB;
  • fields are written in TLV format (Tag-length-value).

The frame contains the following information:

  • protocol version;
  • type of device;
  • Host MAC Address
  • incrementally increasing sequence number.

The RedBox sends the Supervision Frame “on behalf” of the nodes that are connected through it to the PRP network. In this case, the MAC in the Supervision Frame is the MAC of the VDAN and the MAC of the RedBox itself. The address of RedBox is indicated as SrcMAC. RedBox sends a separate Supervision Frame on behalf of each node behind it.



In this screenshot, the frame from RedBox is just open. In the PRP fields, the Source MAC Address is the node located “behind the RedBox” and there is a separate RedBox MAC Address field here. But in the Ethernet II field, the MAC address of the RedBox is indicated as Source MAC.



Supervision frames also have RCT, like other packets in a PRP network.

How is backup management implemented?

Detecting an incorrectly connected interface

DAN or RedBox checks the LAN ID of the received frame. If the LAN IDs of the frame and interface do not match, then the device increments the LAN ID error counter by one.

Let's swap LAN A and LAN B in one of the RedBox's assembled network. Let's try to get the error counter value on these interfaces via SNMP.



On both interfaces we see an almost equal number of errors. The values ​​are different because the interfaces were not connected at the same time, but with a slight difference in time.

Dropping a duplicate

RCT frame contains the sequence field, which contains the sequence number of the frame. Based on this number, a frame drop algorithm, Duplicate Discard, is implemented.

The Duplicate Discard algorithm was discussed in detail in the first article on PRP.

Creating NodeTables

Based on the Supervision frames, the PRP node creates a node table - NodeTable.

The NodeTable for each node (per record) contains the following information:

  • MAC node.
  • The reception time of the last frame from the node to interface A and interface B.
  • SAN flags on interface A or B, i.e. information whether this node is a single attached node or not.
  • The frame counter from this node to interface A and B.
  • Error counter for interfaces A and B.

NodeTable is optional. It can be stored on one of the PRP nodes and this will be enough.


Conclusion

PRP uses an RCT trailer and a Supervision Frame for network diagnostics. This allows you to implement an algorithm for discarding a duplicate frame, determine connection errors, and keep track of all PRP nodes. Accordingly, if the switch reads the RCT incorrectly and believes that it is 802.1q flight, then it can either lose the packet (which is very bad) or delete this field on the Untagged (access) port (which is simply bad).

In the second case, we get not Duplicate Discard, but Duplicate Accept. For each DAN, two packets without RCT will come. Accordingly, the LRE will send both packets to the upper layer, hoping that TCP will handle this. Accordingly, there is no question of any diagnostics in this case.

More articles:


All Articles