Initially, QuadBoxes would just forward the first received
frame (preserving the PathId consisting of the NetId and the A/B
field). This, however, leads to race conditions as to which frame
crosses from one ring to the other (may only get A-frames from one
redundant node on the other ring depending if the A-frame gets to
the QuadBox before the B-frame) and was causing issues with PRP frames through QuadBoxes because
of multiple paths for PRP frames
to flow through the redundant network. To rectify this, QuadBoxes
have a NetId and a A/B designation now.
Figure 2. QuadBoxes with a NetId and a A/B
designation
The NetId allows the QuadBoxes to work together and not reinject
the frames back into the other leg of the complementary QuadBox.
This allows more predictable PRP frame
paths and therefore better accuracy. The Raptor software (1.14.09
and up) has been updated that instead of setting up a RedBox in HSR-HSR
mode (to create half a QuadBox), now the selection is HSR-HSR-A
or HSR-HSR-B to comply with the newer standard (older HSR-HSR modes
will default to HSR-HSR-A mode for backwards compatibility). The
NetId must also be setup for the QuadBox (default is 1 if not setup
and for backwards compatibility). Therefore, older HSR-HSR QuadBox
setups will now form 1A QuadBoxes. All traffic now received on the I-port
on the HSR-HSR RedBox will be marked with the NetId and A/B designation
on the A and B ports connected to the HSR ring
(in the same way as HSR-PRP coupling). The left and right side of
the QuadBox work independently, and therefore, can be set up with
different NetId and A/B designations. Care needs to be taken that
the NedIds are unique on an HSR ring;
else, the two attached network segments will not be able to communicate
with each other.
The updated CLI mode configuration command is as follows.
mode {hsr | prp | hsr-prp-a | hsr-prp-b | hsr-hsr | hsr-hsr-a | hsr-hsr-b} [netid <integer (1-7)>]
NetId can also be changed with the following command even when
active.
hsr-netid <integer (1-7)>
